Re: Threaded PosgreSQL server - Mailing list pgsql-hackers

From Haroldo Stenger
Subject Re: Threaded PosgreSQL server
Date
Msg-id 3C61E492.D9818C2C@adinet.com.uy
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  (Brian Bruns <camber@ais.org>)
List pgsql-hackers

"Marc G. Fournier" wrote:
> 
> On Wed, 6 Feb 2002, Haroldo Stenger wrote:
> 
> > "Marc G. Fournier" wrote:
> > > The thing is, there are several areas where using threads would be a
> > > benefit, from what I've read on this list over the years ... as time goes
> > > on, less and less of the OSs in use dont' have threads, so we have to
> > > start *somewhere* to work towards that sort of hybrid system ...
> >
> > Yes.
> >
> > But, maybe things like full-fledged replication, savepoints/nested
> > transactions, out-of-transaction-scope cursors, and others must have
> > priority over this; and
> 
> If this are priorities for some, we do welcome patches from them to make
> it happen ... it is an open source project ... I am trying to encourage
> one person how has obviously spent a good deal of time on the whole
> threaded issue to start working at using his experience with PgSQL and
> Threading to see what, if anything, can be done to try and keep his work
> and ours from diverging too far ...

Yes, that was my very original thinking. We shouldn't waste programmers or code.
But we're trying to make an idea of cost/benefit/risk. Let's go on with this
discussion, basing it on the pros outlined by the threaded fork knowledge
holders, right? Maybe they are tired, maybe they spent too much effort, and
don't want to do it again. Should that be the case, at least let us obtain
information from the *developent process* of their work in order to measure the
impact on current source tree with current programming force.

> 
> > that mutating PG thread safe, will slow down a 7.3 release a lot,
> > something not wanted by many here.
> 
> Depends on how it is handled ...

How do you see it not slowing down, when key developers said their view is that
multithreading will pose a major obstacle? Are you envisioning any special
approach not already talked about?

Regards,
Haroldo.


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Threaded PosgreSQL server
Next
From:
Date:
Subject: Re: Threaded PosgreSQL server