Re: Threaded PosgreSQL server

On Wed, 2002-02-06 at 23:00, mkscott(at)sacadia(dot)com wrote:
>
>
> 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.

Could you please explain why it was easier to do with your threaded
version than with the standard version ?

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

Do you mean that "it ran at more or less the same speed as when running
comcurrent manual VACUUMs" ?

Btw, have you tried comparing pgbench runs on threaded model vs forked
model. IIRC your code can run both ways.

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

In my experience any code cleanup will eventually pay off (if the
project lives long enough :)

---------
Hannu