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
