Re: MVCC and all that...

From: Justin <zzzzz(dot)graf(at)gmail(dot)com>
To: Ellen Allhatatlan <ellenallhatatlan(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: MVCC and all that...
Date: 2025-09-13 01:54:44
Message-ID: CALL-XeMOBTcnSXc8YWrK49js2U=Q9KEX9pV7MRw17TSWg1OVHQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Sep 12, 2025 at 3:18 PM Ellen Allhatatlan <
ellenallhatatlan(at)gmail(dot)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 Stonebraker
>
>
> 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2025-09-13 09:11:42 Re: Latest patches break one of our unit-test, related to RLS
Previous Message Tom Lane 2025-09-13 01:53:17 Re: Latest patches break one of our unit-test, related to RLS