Re: Threaded PosgreSQL server - Mailing list pgsql-hackers

From
Subject Re: Threaded PosgreSQL server
Date
Msg-id Pine.GSO.4.10.10202061228090.2099-100000@goldengate.kojoworldwide.com.
Whole thread Raw
In response to Re: Threaded PosgreSQL server  ("Marc G. Fournier" <scrappy@hub.org>)
Responses Re: Threaded PosgreSQL server  ("Marc G. Fournier" <scrappy@hub.org>)
Re: Threaded PosgreSQL server  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers

On Wed, 6 Feb 2002, Marc G. Fournier wrote:

> Right now, from everythign I've heard, making the code thread-safe is one
> big onerous task ... but if we were to start incorporating changes from
> the 'thread work' that is being done now, into the base server, and ppl
> start thinking thread-safe when they are coding new stuff, over time, this
> task becomes smaller ...
> 

I agree, once the move is made to thread-safe it becomes much easier to
maintain thread-safe code.  I also very much like the idea of multiple
thread/process models that could be chosen from.  I think the question has
always been the
inital cost vs. benefit.  The group has not seen much to be gained for
the amount of initial work involved.  After working with the code, I too
felt it wasn't worth it.  

After revisiting the threaded code after a long break I now see some real
benefits to threading.  For example,  I was able to incorporate Tom Lane's
lazy_vacuum code to do relation clean up automatically when a threshold of
page writes occurred.  I was also able to use the freespace information to
be shared among threads in the process without touching shared mem.  As a
result, a pgbench run with 20 clients and over 1,000,000
trasactions maintained a more or less constant tps with manual
vacuum commands and far less heap expansion.  You can do this with
processes (planned for 7.3 I think) but I
think it was much easier with threads.  Other things may open up with
threads as well like Java stored procedures.  Anyway, now I think it is
worth it.


Myron
mkscott@sacadia.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: JOIN between three *simple* tables ...
Next
From: "Marc G. Fournier"
Date:
Subject: Re: JOIN between three *simple* tables ...