Kris Kennaway wrote:
On Tue, Apr 17, 2007 at 02:51:55PM -0400, Kevin Way wrote:
I built 7.0 as of 6 days ago, and ran the same test using 8-cores, ULE
and 4BSD. The results are available at:
http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
Unfortunately
On Tue, 17 Apr 2007 14:51:55 -0400
Kevin Way <[EMAIL PROTECTED]> wrote:
> I built 7.0 as of 6 days ago, and ran the same test using 8-cores, ULE
> and 4BSD. The results are available at:
>
> http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
>
> Unfortunately,
On Tue, Apr 17, 2007 at 02:51:55PM -0400, Kevin Way wrote:
> I built 7.0 as of 6 days ago, and ran the same test using 8-cores, ULE
> and 4BSD. The results are available at:
>
> http://blog.insidesystems.net/articles/2007/04/11/postgresql-scaling-on-6-2-and-7-0
>
> Unfortunately, I can't run t
Robert Watson wrote:
On Tue, 10 Apr 2007, Kevin Way wrote:
Kris Kennaway wrote:
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only
On Tue, 10 Apr 2007, Kevin Way wrote:
Kris Kennaway wrote:
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently whenever
the semaphore state changes, all processes sleeping on the semaphore are
woken, even if we only have released enough r
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Tue, Apr 10, 2007 at 02:46:56PM -0400, Tom Lane wrote:
>> Oh, I'm sure the BSD kernel acts as you describe. But Mark's point is
>> that Postgres never has more than one process waiting on any particular
>> SysV semaphore, and so the problem doesn't re
Kris Kennaway <[EMAIL PROTECTED]> writes:
> On Tue, Apr 10, 2007 at 05:36:17PM -0400, Tom Lane wrote:
>> Anyway I'd be interested to know what the test case is, and which PG
>> version you were testing.
> I used 8.2 (and some older version when I first noticed it a year ago)
> and either sysbench
Kris Kennaway <[EMAIL PROTECTED]> writes:
> I have not studied the exact code path, but there are indeed multiple
> wakeups happening from the semaphore code (as many as the number of
> active postgresql processes). It is easy to instrument
> sleepq_broadcast() and log them when they happen.
Ther
On Tue, Apr 10, 2007 at 06:26:37PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Tue, Apr 10, 2007 at 05:36:17PM -0400, Tom Lane wrote:
> >> Anyway I'd be interested to know what the test case is, and which PG
> >> version you were testing.
>
> > I used 8.2 (and some ol
On Tue, Apr 10, 2007 at 05:36:17PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > I have not studied the exact code path, but there are indeed multiple
> > wakeups happening from the semaphore code (as many as the number of
> > active postgresql processes). It is easy to in
On Tue, Apr 10, 2007 at 03:52:00PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> > On Tue, Apr 10, 2007 at 02:46:56PM -0400, Tom Lane wrote:
> >> Oh, I'm sure the BSD kernel acts as you describe. But Mark's point is
> >> that Postgres never has more than one process waiting
On Tue, Apr 10, 2007 at 02:46:56PM -0400, Tom Lane wrote:
> Kris Kennaway <[EMAIL PROTECTED]> writes:
> >>> Make SYSV semaphores less dumb about process wakeups. Currently
> >>> whenever the semaphore state changes, all processes sleeping on the
> >>> semaphore are woken, even if we only have rele
Kris Kennaway <[EMAIL PROTECTED]> writes:
>>> Make SYSV semaphores less dumb about process wakeups. Currently
>>> whenever the semaphore state changes, all processes sleeping on the
>>> semaphore are woken, even if we only have released enough resources
>>> for one waiting process to claim.
>> Co
On Tue, Apr 10, 2007 at 10:23:42AM -0400, Tom Lane wrote:
> Mark Kirkwood <[EMAIL PROTECTED]> writes:
> > Kris Kennaway wrote:
> >> If so, then your task is the following:
> >>
> >> Make SYSV semaphores less dumb about process wakeups. Currently
> >> whenever the semaphore state changes, all proc
On Tue, Apr 10, 2007 at 10:41:04PM +1200, Mark Kirkwood wrote:
> Kris Kennaway wrote:
> >If so, then your task is the following:
> >
> >Make SYSV semaphores less dumb about process wakeups. Currently
> >whenever the semaphore state changes, all processes sleeping on the
> >semaphore are woken, eve
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Kris Kennaway wrote:
>> If so, then your task is the following:
>>
>> Make SYSV semaphores less dumb about process wakeups. Currently
>> whenever the semaphore state changes, all processes sleeping on the
>> semaphore are woken, even if we only have rel
Mark Kirkwood wrote:
> Kris Kennaway wrote:
> >If so, then your task is the following:
> >
> >Make SYSV semaphores less dumb about process wakeups. Currently
> >whenever the semaphore state changes, all processes sleeping on the
> >semaphore are woken, even if we only have released enough resource
Kris Kennaway wrote:
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough resources
for one waiting process to claim.
On Tue, Apr 10, 2007 at 12:04:32AM -0400, Kevin Way wrote:
> Kris Kennaway wrote:
> >If so, then your task is the following:
> >
> >Make SYSV semaphores less dumb about process wakeups. Currently
> >whenever the semaphore state changes, all processes sleeping on the
> >semaphore are woken, even if
Kris Kennaway wrote:
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough resources
for one waiting process to claim.
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough resources
for one waiting process to claim. i.e. there is a thunde
21 matches
Mail list logo
