[solid_fuel]

> Current Postgres is per-process. Switching to threading yields performance improvements.

Please describe in detail what you believe this means and the mechanism by which switching from processes to threads improves performance.

[rjh29]

There are hundreds of comment chains about this already, go troll somewhere else.

[solid_fuel]

If you’re going to make a confident blanket claim, be ready to back it up - and asking for clarification is not trolling, by the way. You should be ready to engage in technical conversations if you want to make technical claims.

[rjh29]

I'm not interested in a technical conversation with you; I was answering someone else. The top voted comment thread of this page, which dominates discussion, already covers everything you'd want to know.

[solid_fuel]

Ah yeah, what I figured. You clearly have no idea what you're talking about. Don't get all mad when someone calls you out on it.

By the way, just so you have some concept of what the actual problem is despite your resistance to education:

Simply switching from processes to threads will not yield the claimed performance increases. A 300x improvement on analytic workflows? From a direct transliteration? Your BS alarms should be going off. They should be screaming "5 Alarm Fire".

The only way they got that increase was by breaking the synchronization mechanisms that provide ACID guarantees in Postgres, otherwise a direct rewrite would expect very similar performance.

[rjh29]

The author was talking about eliminating memory being copied between processes. That's a performance improvement. I don't know how the 300x improvement was made or whether that's even real - you should really be arguing with the author about that. I didn't seriously put stock into it because you know, they used AI to rewrite it. I doubt their testing methodology is sound.

I appreciate the condescension though. Thanks for teaching stupid old me how a database works.

[solid_fuel]

> Thanks for teaching stupid old me how a database works.

You're welcome, someone had to.

[cowboylowrez]

There is an expectation that threads are more performant than processes all else being equal. Obviously there is some work involved to make "all else be equal", like maybe threads have less isolation from each other etc but if you can mechanically convert code to use threads where it used to use processes I can see the claim standing up.

[solid_fuel]

Threads generally have less memory overhead and context switching between them is theoretically faster, but as I suspect you know it is situational and not as simple as just s/process/thread/g. There are many tradeoffs, including the loss of memory isolation, and since Postgres is a network application which holds a rather important position in most architectures, proper memory isolation is very important.

Switching to threads doesn't guarantee weaker isolation, just like it doesn't guarantee better performance, but those nuances are why "switching to threading yields performance improvements" is over simplified to the point of uselessness. It simply reeks of the same kind of ignorance that used to drive statements like "rust doesn't have vulnerabilities" and "rewrite it in javascript for web scale performance".

[cowboylowrez]

I do agree, but maybe there is a valid mechanical conversion thats applicable in the postgresql codebase? I do get what you're saying but on the other hand, if he's passing tests with his conversion then this is different than some hypothetical, I'm just saying I would believe his claim on this one. I'm not going to port my erp to it yet but the performance win could actually be there.