Re: 7.2 items

From: "carl garland" <carlhgarland(at)hotmail(dot)com>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us, pgman(at)candle(dot)pha(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 7.2 items
Date: 2001-05-13 08:19:38
Message-ID: F262H5n00zepDI8NFr900005349@hotmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-05-13 10:11:12 Re: Why do we use Tcl's compiler and flags?
Previous Message carl garland 2001-05-13 05:25:18 Re: 7.2 items