5 ms·

That's really not right. Andres Freund and Robert Haas at least are pretty clearly theoretically in support (which is all anyone can offer at this point). Tho

That's really not right. Andres Freund and Robert Haas at least are pretty clearly theoretically in support (which is all anyone can offer at this point). Those are some big names to have in the "aye" column.

tonymillion 3y ago
I saw a bunch of nays and a lot of “abstains” a lack of vote against something is not a vote of approval. 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
- anarazel 3y ago
  > I saw a bunch of nays and a lot of “abstains” a lack of vote against something is not a vote of approval. 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.
  - tonymillion 3y ago
    Apologies autocorrect substituted Moor for Lane. 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
    - anarazel 3y ago
      > Apologies autocorrect substituted Moor for Lane. > > But I believe you knew that but pedantry stopped you from just suggesting it. 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).

tonymillion 3y ago

I saw a bunch of nays and a lot of “abstains” a lack of vote against something is not a vote of approval. 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

anarazel 3y ago
> I saw a bunch of nays and a lot of “abstains” a lack of vote against something is not a vote of approval. 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.
- tonymillion 3y ago
  Apologies autocorrect substituted Moor for Lane. 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
  - anarazel 3y ago
    > Apologies autocorrect substituted Moor for Lane. > > But I believe you knew that but pedantry stopped you from just suggesting it. 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).