Re: Threaded PosgreSQL server - Mailing list pgsql-hackers

From D. Hageman
Subject Re: Threaded PosgreSQL server
Date
Msg-id Pine.LNX.4.44.0202071552060.2624-100000@typhon.eecs.ku.edu
Whole thread Raw
In response to Re: Threaded PosgreSQL server  (mlw <markw@mohawksoft.com>)
Responses Re: Threaded PosgreSQL server  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 7 Feb 2002, mlw wrote:

<SNIP a bunch crap that will hopefully be implicitly explained 
and understand by the comments below>

> There are, AFAIK two reasons to thread PostgreSQL:
> 
> (1) Run the multiple connections in their own thread with the assumption
> that this is more efficient for [n] reasons.
> (2) Run a single query across multiple threads, thus parallelizing the
> query engine.

(3) Parallelize house keeping (for example vacuums) of the database.  I 
think they are going to call this processes or something slated for the 
next version? 

(4) Replication

(5) Referential Integritity cleanups

(6) EXOTIC FEATURES: crossdb

Oh yeah ... and we might be able to drop the whole startup time section 
from the TODO list.  It all depends on how one wants to implement the 
threads into postgresql.  Then again ... maybe a task of this endeavor 
would be more appropriately forked off and proceeded on as a seperate 
project (as it kinda as already been done).

> I guess all I am saying, is that a person's time is really the only
> limited resource. Tom, Bruce, Marc, Peter and everyone else have a
> limited amount of time. If I could influence how those guys spend their
> time, I would hope they spent time working on improving the
> functionality of PostgreSQL, not the tedium of making it thread safe.

The people that do the biggest amount of coding should definately code 
what they feel is the best to work on - NO one is arguing that.  If a few 
of them want to assist in this endeavor then they should do that as well.  
Most importantly - we shouldn't belittle the efforts of those that do see 
the vision of how this could be beneficial in the long run.  My point is 
that I see more people wasting time complaining then it would take to make 
up a list of coding practices to follow for future work that will make the 
postgresql code base better.  (Come on ... the first thing a programmer is 
taught is that global variables are BAD).

-- 
//========================================================\\
||  D. Hageman                    <dhageman@dracken.com>  ||
\\========================================================//



pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: Threaded PosgreSQL server
Next
From: Doug McNaught
Date:
Subject: Re: Threaded PosgreSQL server