Re: MVCC and all that...

On Thu, Sep 11, 2025 at 5:38 AM Ellen Allhatatlan <
ellenallhatatlan(at)gmail(dot)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