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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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