Skip site navigation (1) Skip section navigation (2)

Re: Spinlock performance improvement proposal

From: "D(dot) Hageman" <dhageman(at)dracken(dot)com>
To: Doug McNaught <doug(at)wireboard(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spinlock performance improvement proposal
Date: 2001-09-26 20:03:11
Message-ID: Pine.LNX.4.33.0109261446370.1616-100000@typhon.dracken.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 26 Sep 2001, Doug McNaught wrote:

> "D. Hageman" <dhageman(at)dracken(dot)com> writes:
> 
> > The plan for the new spinlocks does look like it has some potential.  My 
> > only comment in regards to permformance when we start looking at SMP 
> > machines is ... it is my belief that getting a true threaded backend may 
> > be the only way to get the full potential out of SMP machines.
> 
> Depends on what you mean.  For scaling well with many connections and
> simultaneous queries, there's no reason IMHO that the current
> process-per-backend model won't do, assuming the locking issues are
> addressed. 

Well, I know the current process-per-backend model does quite well.  My 
argument is not that it fails to do as intended.  My original argument is 
that it is belief (at the momment with the knowledge I have) to get the 
full potential out of SMP machines - threads might be the way to go.  The 
data from RedHat is quite interesting, so my feelings on this might 
change or could be re-inforced.  I watch anxiously ;-)

> If you're talking about making a single query use multiple CPUs, then
> yes, we're probably talking about a fundamental rewrite to use threads 
> or some other mechanism.

Well, we have several thread model ideologies that we could chose from.  
Only experimentation would let us determine the proper path to follow and 
then it wouldn't be ideal for everyone.  You kinda just have to take the 
best scenerio and run with it.  My first inclination would be something 
like a thread per connection (to reduce connection overhead), but then we 
could run into limits on different platforms (threads per process).  I 
kinda like the idea of using a thread for replication purposes ... lots 
of interesting possibilities exist and I will be first to admit that I 
don't have all the answers.  

-- 
//========================================================\\
||  D. Hageman                    <dhageman(at)dracken(dot)com>  ||
\\========================================================//


In response to

pgsql-hackers by date

Next:From: Brent R. MatzelleDate: 2001-09-26 20:05:10
Subject: Re: PostgreSQL / PHP Overrun Error
Previous:From: Bruce MomjianDate: 2001-09-26 19:53:29
Subject: Re: LOCAL_CREDS -> SCM_CREDS in src/backend/libpq/auth.c:535

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group