[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.