Heikki: let’s make Postgres multithreaded, unless any of you have objections
Most of the rest of the core team: it would be a disaster or at the very least incredibly difficult
Heikki: okay so I’m not hearing any objections so let’s go
Most of the rest of the core team: …
Heikki (covering ears): lah lah lah
There was a very poignant message in amongst that mess which to summarize said:
Doing this will stall Postgres development for several versions (read years) and will divert development resources away from features while the devs are busy putting out fires.
Basically Postgres loses 10% performance vs threads[1] because of its Process based model, and leaves a bunch of caching related performance on the table but has the benefit that a process crash doesn’t bring down the entire database.
[1] the 10% figure is mentioned more than once
Personal View: Postgres development stalled in the early/mid 2000s and MySQL rose to prominence (so around V7/V8 time). While there were many people involved, I believe Tom Moor was instrumental in “dragging” Postgres development into V9/V10 land where it really started out-evolving it’s competition, terraforming the landscape for all the features it has now (thanks to every contributor who helped make it what it is today) this proposal while maybe well intentioned has the potential to drag Postgres into a multi year “dark age” of buggy code and perceived lack of progress. To be hyperbolic about it - that could be the start of an extinction event
There's definitely some ayes, including the people mentioned in the post upthread.
> Basically Postgres loses 10% performance vs threads[1] because of its Process based model, and leaves a bunch of caching related performance on the table but has the benefit that a process crash doesn’t bring down the entire database.
I don't think that's accurate at all. One of the big problems is that it forces us to make bad architectural choices to deal with the limitations, including a lot of code duplication.
> Basically Postgres loses 10% performance vs threads[1] because of its Process based model, and leaves a bunch of caching related performance on the table but has the benefit that a process crash doesn’t bring down the entire database.
A process crash does bring the entire database down today.
> Personal View: Postgres development stalled in the early/mid 2000s and MySQL rose to prominence (so around V7/V8 time). While there were many people involved, I believe Tom Moor was instrumental in “dragging” Postgres development into V9/V10 land where it really started out-evolving it’s competition, terraforming the landscape for all the features it has now (thanks to every contributor who helped make it what it is today) this proposal while maybe well intentioned has the potential to drag Postgres into a multi year “dark age” of buggy code and perceived lack of progress. To be hyperbolic about it - that could be the start of an extinction event
Nobody of that name has worked meaningfully on postgres from what I can tell. And I worked on PG during that time.
But I believe you knew that but pedantry stopped you from just suggesting it.
In addition my post should in no way be considered a slight towards the rest of the Postgres developers, I just remember him as having a singular focus to product that I have a lot of respect for
I was wondering about it, but thought it wouldn't really make sense, given that Tom was the instrumental developer starting far before "V9/V10 land". If anything that time was marked by Tom having a bit less of an outsize role (by virtue of more others contributing, not because he wasn't doing important work anymore).