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>
 <CAHyXU0zD43sbm5znedzG__gXadrkVOt7_CNHiYCtHNb3vdtOOA@mail.gmail.com> <CAMLfE0Pev+Y-sahbjctNwZzLtiNOp5A8vy23j2MmiES-mc6g5A@mail.gmail.com>
In-Reply-To: <CAMLfE0Pev+Y-sahbjctNwZzLtiNOp5A8vy23j2MmiES-mc6g5A@mail.gmail.com>
From: Justin <zzzzz.graf@gmail.com>
Date: Fri, 12 Sep 2025 21:54:44 -0400
Message-ID: <CALL-XeMOBTcnSXc8YWrK49js2U=Q9KEX9pV7MRw17TSWg1OVHQ@mail.gmail.com>
Subject: Re: MVCC and all that...
To: Ellen Allhatatlan <ellenallhatatlan@gmail.com>
Cc: Merlin Moncure <mmoncure@gmail.com>, pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000009b07fb063ea50e51"
Archived-At: <https://www.postgresql.org/message-id/CALL-XeMOBTcnSXc8YWrK49js2U%3DQ9KEX9pV7MRw17TSWg1OVHQ%40mail.gmail.com>
Precedence: bulk

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

On Fri, Sep 12, 2025 at 3:18=E2=80=AFPM Ellen Allhatatlan <
ellenallhatatlan@gmail.com> wrote:

> You, (Merlin Moncure) said:
>
> > Technical discussions from the 80's are more or less historically
> interesting only.
>
> I agree with your technical points - and the fact that I brought up
> "history".
>
> I was replying to Justin in this context:
>
> I wrote:
>
> > AIUI, Michael Stonebraker suggested that the process model
> > would/should be "upgraded" to a threaded one at some point in the
> > system's developement?
>
> To which Justin replied:
>
> > I am going to need a source on this.  Process vs Threads: pro and cons
> are very well documented and proven today.
>
> Hence the history lesson - to provide the "source" from Michael Stonebrak=
er
>
>
> Thank you for the documents.

The reason PostgreSQL was not developed using threads was that it was not
technically feasible at the time.  The entire idea of PostgreSQL was
experimental.  One of the things you want to do is test out as many ideas
as you can feasibly do .

Jump forward 20-40 years into the future, what have we learned,  What was
thought would be a clear advantage for threads has been shown not to be a
clear advantage.

Each approach has pluses and minuses. I agree with many others that the
time spent trying to get threads to work in PostgreSQL is just not worth it
when we should be spending our time other issues

moving XID to 64 bit and moving away from the current file format and stop
storing  row versions in the tables,  would pay far more dividends in
performance than threading will...

The append only storage design  aka Storing row versions in the table is a
Stonebraker idea,  which would allow for Time-Travel Queries, I am pretty
sure this proved to be unworkable.

PostgreSQL table layout and MVCC being tracked in the tables has been shown
to be problematic and a performance bottleneck .  Just look at all the time
the community has spent making AutoVacuum better and all the IO spent
keeping the XID from wrapping around, or HOT updates or the FILL FACTOR
setting.

The question I should have asked is what is Stonebraker's current thought
on process vs threading today.

Thank you
Justin

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

<div dir=3D"ltr"><div dir=3D"ltr"><div><br></div></div><div class=3D"gmail_=
quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, =
Sep 12, 2025 at 3:18=E2=80=AFPM Ellen Allhatatlan &lt;<a href=3D"mailto:ell=
enallhatatlan@gmail.com">ellenallhatatlan@gmail.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">You, (Merlin Moncure) sa=
id:<br>
<br>
&gt; Technical discussions from the 80&#39;s are more or less historically =
interesting only.<br>
<br>
I agree with your technical points - and the fact that I brought up &quot;h=
istory&quot;.<br>
<br>
I was replying to Justin in this context:<br>
<br>
I wrote:<br>
<br>
&gt; AIUI, Michael Stonebraker suggested that the process model<br>
&gt; would/should be &quot;upgraded&quot; to a threaded one at some point i=
n the<br>
&gt; system&#39;s developement?<br>
<br>
To which Justin replied:<br>
<br>
&gt; I am going to need a source on this.=C2=A0 Process vs Threads: pro and=
 cons are very well documented and proven today.<br>
<br>
Hence the history lesson - to provide the &quot;source&quot; from Michael S=
tonebraker<br>
<br><br></blockquote>Thank you for the documents.<br><br>The reason Postgre=
SQL was not developed using threads was that it was not technically feasibl=
e at the time.=C2=A0 The entire idea of PostgreSQL was experimental.=C2=A0 =
One of the things you want to do is test out as many ideas as you can feasi=
bly=C2=A0do .<br><br>Jump forward=C2=A020-40 years into the future, what ha=
ve we learned,=C2=A0 What was thought would be a clear advantage for thread=
s has been shown not to be a clear advantage.<div><br></div><div>Each appro=
ach has pluses and minuses. I agree with many=C2=A0others that the time spe=
nt trying to get threads to work in PostgreSQL is just not worth it when we=
 should be spending our time other issues<br><br>moving XID to 64 bit and m=
oving away from the current file format and stop storing=C2=A0 row versions=
 in the tables,=C2=A0 would pay far more dividends in performance than thre=
ading will...<br><br>The=C2=A0append only storage design=C2=A0 aka Storing =
row versions in the table is a Stonebraker idea,=C2=A0 which would allow fo=
r Time-Travel Queries, I am pretty sure this proved to be unworkable.=C2=A0=
</div><div><br></div><div>PostgreSQL table layout and MVCC being tracked in=
 the tables has been shown to be problematic and a performance bottleneck .=
=C2=A0 Just look at all the time the community has spent making AutoVacuum =
better and all the IO spent keeping the XID from wrapping around, or HOT up=
dates or the FILL FACTOR setting.=C2=A0 =C2=A0=C2=A0<br><br></div><div>The =
question I should have asked is what is Stonebraker&#39;s current thought o=
n process vs threading today.=C2=A0 <br><br>Thank you<br>Justin=C2=A0</div>=
</div></div>

--0000000000009b07fb063ea50e51--