Re: MVCC and all that...
От | Merlin Moncure |
---|---|
Тема | Re: MVCC and all that... |
Дата | |
Msg-id | CAHyXU0zD43sbm5znedzG__gXadrkVOt7_CNHiYCtHNb3vdtOOA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: MVCC and all that... (Ellen Allhatatlan <ellenallhatatlan@gmail.com>) |
Ответы |
Re: MVCC and all that...
Re: MVCC and all that... |
Список | pgsql-general |
On Thu, Sep 11, 2025 at 5:38 AM Ellen Allhatatlan <ellenallhatatlan@gmail.com> wrote:
"A last aspect of our design concerns the operating system process
structure. Currently, POSTGRES runs as one process for each active
user. This was done as an expedient to get a system operational as
quickly as possible. We plan on converting POSTGRES to use lightweight
processes available in the operating systems we are using. These
include PRESTO for the Sequent Symmetry and threads in Version 4 of
Sun/OS."
Technical discussions from the 80's are more or less historically interesting only. At that time, support for threads was pretty immature relative to today, and the general state of operating system technology was pretty crude by modern standards. Process spinup via fork() might also have been much more performance relevant that it is today, and various synchronization primitives might have been pretty lousy as well.
I find the threads/processes debate to be pretty silly in general. Things have changed a lot, IPC has improved a lot, and I would argue the decision to use/not use SSL is much more important to database session startup than the database spinning up a process vs a thread. The mythology around this architectural decision is pervasive and mostly incorrect IMO, and there are many high quality solutions to work around this connection poolers, pgbouncer, etc, which are essentially employed against all databases in some or another way, and are essentially universally employed in scenarios where scale and reliable performance is important.
Maybe Microsoft is the odd man out here as its weird non-standard process model made porting multi process servers (including postgres) difficult and imperformant. Those issues are (mostly) long since worked out though.
Having said that, I suspect 3rd party vendor support for postgres/microsoft being relatively limited would be much more based in business calculation rather than technical constraints.
Final thoughts on this: firebird (fmrly interbase) did not achieve the level of success in the market that postgres, even though they may have been similarly positioned. My take: that disparity in success has more to do with postgres having a more open development model, stronger community, and (especially) timing; postgres was pretty well established in the open source world when Borland open sourced it around the year 2000. Firebird had (and has) some neat stuff, in particular a nice embedding option and strong windows support, but the market was already pretty crowded at that time.
merlin
В списке pgsql-general по дате отправления: