Re: 7.2 items - Mailing list pgsql-hackers

From carl garland
Subject Re: 7.2 items
Date
Msg-id F262H5n00zepDI8NFr900005349@hotmail.com
Whole thread Raw
In response to 7.2 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
> > Here is a small list of big TODO items.  I was wondering which ones
> > people were thinking about for 7.2?
>
>Other than that, I'm mostly thinking about performance improvements
>for 7.2, not features ... as far as my personal plans go, that is.

This issue was brought up before as well but after searching the
archives I couldn't find original post, but it didnt seem to be
addressed by any core hackers.  From the linux kernel mailing lists:
http://www.appwatch.com/lists/linux-kernel/Week-of-Mon-20010305/026326.html


>Tridge and I tried out the postgresql benchmark you used here and this
>contention is due to a bug in postgres. From a quick strace, we found
>the threads do a load of select(0, NULL, NULL, NULL, {0,0}). Basically all
>threads are pounding on schedule().

>Our guess is that the app has some form of userspace synchronisation
>(semaphores/spinlocks). I'd argue that the app needs to be fixed not the
>kernel, or a more valid test case is put forwards. :)


And later here 
http://www.appwatch.com/lists/linux-kernel/Week-of-Mon-20010305/027408.html 
:

>>Thanks for looking into postgresql/pgbench related locking.  Yes, 
>>apparently postgresql uses a synchronization scheme that uses select()
>>to effect delays for backing off while attempting to acquire a lock.
>>However, it seems to me that runqueue lock contention was not entirely due 
>>to postgresql code, since it was largely alleviated by the multiqueue 
>>scheduler patch.

>Im not saying that the multiqueue scheduler patch isn't needed, just that
>this test case is caused by a bug in postgres. We shouldn't run around
>fixing symptoms - dropping the contention in the runqueue lock might not
>change the overall performance of the benchmark, on the other hand
fixing the spinlocks in postgres probably will.

Might be worth a look from core members to see if there really are
issues here, the thread is about 8 msgs.

Best Regards,
Carl Garland
On the other hand, if postgres still pounds on the runqueue lock after
the bug has been fixed then we need to look at the multiqueue patch.


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com



pgsql-hackers by date:

Previous
From: "carl garland"
Date:
Subject: Re: 7.2 items
Next
From: Peter Eisentraut
Date:
Subject: Re: Why do we use Tcl's compiler and flags?