Re: Spinlock performance improvement proposal

Поиск
Список
Период
Сортировка
От D. Hageman
Тема Re: Spinlock performance improvement proposal
Дата
Msg-id Pine.LNX.4.33.0109261446370.1616-100000@typhon.dracken.com
обсуждение исходный текст
Ответ на Re: Spinlock performance improvement proposal  (Doug McNaught <doug@wireboard.com>)
Список pgsql-hackers
On 26 Sep 2001, Doug McNaught wrote:

> "D. Hageman" <dhageman@dracken.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@dracken.com>  ||
\\========================================================//



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: LOCAL_CREDS -> SCM_CREDS in src/backend/libpq/auth.c:535
Следующее
От: Vince Vielhaber
Дата:
Сообщение: casting for dates