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>
In-Reply-To: <CALL-XeN=8nYHVw0Gn510feRbXJSRzEf8XeJxooWVpoZ=p_98Mw@mail.gmail.com>
From: Ellen Allhatatlan <ellenallhatatlan@gmail.com>
Date: Thu, 11 Sep 2025 12:38:32 +0100
Message-ID: <CAMLfE0PkJYEWS0Hu_+M18rAJx9tzHEUisC3+vruEq_xCbNgTYQ@mail.gmail.com>
Subject: Re: MVCC and all that...
To: Justin <zzzzz.graf@gmail.com>
Cc: Merlin Moncure <mmoncure@gmail.com>, pgsql-general <pgsql-general@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAMLfE0PkJYEWS0Hu_%2BM18rAJx9tzHEUisC3%2BvruEq_xCbNgTYQ%40mail.gmail.com>
Precedence: bulk

>> AIUI, Michael Stonebraker suggested that the process model
>> would/should be "upgraded" to a threaded one at some point in the
>> system's developement?


> I am going to need a source on this.  Process vs Threads: pro and cons are very well documented and proven today.

Ask, and it will be given to you;
seek, and you will find;
knock, and it will be opened to you!
Matthew 7:7

From here: https://dsf.berkeley.edu/papers/ERL-M85-95.pdf (bottom of page 13) -

5.1. Process Structure - Stonebraker expresses regret that the project
doesn't have the resources to use the "server model" - i.e. threading:

"The server model has many performance benefits (e.g., sharing of open
file descriptors and buffers and optimized task switching and message
sending overhead) in a large machine environment in which high
performance is critical. However, this approach requires that a fairly
complete special-purpose operating system be built. In constrast, the
process-per-user model is simpler to implement but will not perform as
well on most conventional operating systems. We decided after much
soul searching to implement POSTGRES using a process-per-user model
architecture because of our limited programming esources. POSTGRES is
an ambitious undertaking and we believe the additional complexity
introduced by the server architecture was not worth the additional
risk of not getting the system running. Our current plan then is to
implement POSTGRES as a process-per-user model on Unix 4.3 BSD"

No date, but the latest date in the references was 1986.

and from here https://dsf.berkeley.edu/papers/ERL-M90-34.pdf (middle
of page 29):

"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."

Again, no date, but this time the latest reference was from 1989 -
(threading advancing?).

The use of "because of our limited programming esources" (1st ref.)
and "expedient" (2nd) clearly indicates to me that Stonebraker was
eyeing up the threading model and saw the per-process one as an
albatross around the neck of the project!


I hope my sources are sufficient?

--

El!