MIME-Version: 1.0
References: <CAMLfE0MAVH5YORs0OKmD=fFWH9EtuNsnhViti=+hkp3Kbz-Gfw@mail.gmail.com>
 <CAHyXU0yrwoEYia0mZhpjQLMdd-WXpWFM+Au1jXQpk3MtBvdogw@mail.gmail.com>
 <CAMLfE0MWqALMJ99dpFniZ1xknCgHj4ETPWro+Ry9awPUG1OKMw@mail.gmail.com>
 <CAHyXU0y2gZfH_ZomazQB7H0KkuyV3QofvuvZcSYXEhpotG=hMA@mail.gmail.com>
 <CALL-XeM=0oH=2ECawmyCOv2umKF1nyqr97CuQXiPfO39uhCucQ@mail.gmail.com>
 <CAMLfE0O5YPhrXOWP1pLTLHy-rKDut5cmiGyuxo3d43LCGEkJYg@mail.gmail.com>
 <CALL-XeN=8nYHVw0Gn510feRbXJSRzEf8XeJxooWVpoZ=p_98Mw@mail.gmail.com> <CAMLfE0PkJYEWS0Hu_+M18rAJx9tzHEUisC3+vruEq_xCbNgTYQ@mail.gmail.com>
In-Reply-To: <CAMLfE0PkJYEWS0Hu_+M18rAJx9tzHEUisC3+vruEq_xCbNgTYQ@mail.gmail.com>
From: Merlin Moncure <mmoncure@gmail.com>
Date: Thu, 11 Sep 2025 10:52:45 -0600
Message-ID: <CAHyXU0zD43sbm5znedzG__gXadrkVOt7_CNHiYCtHNb3vdtOOA@mail.gmail.com>
Subject: Re: MVCC and all that...
To: Ellen Allhatatlan <ellenallhatatlan@gmail.com>
Cc: Justin <zzzzz.graf@gmail.com>, pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000008725d6063e895e63"
Archived-At: <https://www.postgresql.org/message-id/CAHyXU0zD43sbm5znedzG__gXadrkVOt7_CNHiYCtHNb3vdtOOA%40mail.gmail.com>
Precedence: bulk

--0000000000008725d6063e895e63
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 11, 2025 at 5:38=E2=80=AFAM 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

--0000000000008725d6063e895e63
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Sep 11, 2025 at 5:38=E2=80=AFAM E=
llen Allhatatlan &lt;<a href=3D"mailto:ellenallhatatlan@gmail.com">ellenall=
hatatlan@gmail.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quot=
e_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&quot;A last aspect of our design concerns the operating system process<br>
structure. Currently, POSTGRES runs as one process for each active<br>
user. This was done as an expedient to get a system operational as<br>
quickly as possible. We plan on converting POSTGRES to use lightweight<br>
processes available in the operating systems we are using. These<br>
include PRESTO for the Sequent Symmetry and threads in Version 4 of<br>
Sun/OS.&quot;<br></blockquote><div><br></div><div>Technical discussions fro=
m the 80&#39;s are more or less historically interesting only.=C2=A0 At tha=
t time, support for threads was pretty immature relative to today, and the =
general state of operating system=C2=A0technology was pretty crude by moder=
n standards.=C2=A0 Process spinup via fork() might also have been much more=
 performance relevant that it is today, and various synchronization primiti=
ves might have been pretty lousy as well.</div><div><br></div><div>I find t=
he threads/processes debate to be pretty silly in general. Things have chan=
ged a lot, IPC has improved a lot, and I would argue the decision to use/no=
t use SSL is much more important to database session startup than the datab=
ase spinning up a process vs a thread.=C2=A0 The mythology around this arch=
itectural decision is pervasive and mostly incorrect IMO, and there are man=
y high quality solutions to work around this connection poolers, pgbouncer,=
 etc, which are essentially employed against all databases in some or anoth=
er way, and are essentially universally employed in scenarios where scale a=
nd reliable performance is important.</div><div><br></div><div>Maybe Micros=
oft is the odd man out here as its weird non-standard process model made po=
rting multi process servers (including postgres) difficult and imperformant=
.=C2=A0 Those issues are (mostly) long since worked out though.=C2=A0</div>=
<div><br></div><div>Having said that, I suspect 3rd party vendor support fo=
r postgres/microsoft being relatively limited would be much more based in b=
usiness calculation rather than technical constraints.=C2=A0</div><div><br>=
</div><div>Final thoughts on this: firebird (fmrly interbase) did not achie=
ve the level of success in the market that postgres, even though they may h=
ave been similarly positioned.=C2=A0 My take: that disparity in success has=
 more to do with postgres having a more open development model, stronger co=
mmunity, and (especially) timing; postgres was pretty well established in t=
he open source world when Borland open sourced it around the year 2000.=C2=
=A0 Firebird had (and has) some neat stuff, in particular=C2=A0a nice embed=
ding option and strong windows support, but the market was already pretty c=
rowded at that time.</div><div><br></div><div>merlin</div><div><br></div></=
div></div>

--0000000000008725d6063e895e63--