Re: Anyone interested in improving postgresql scaling?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
Cc: Kris Kennaway <kris(at)obsecurity(dot)org>, current(at)FreeBSD(dot)org, performance(at)FreeBSD(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Anyone interested in improving postgresql scaling?
Date: 2007-04-10 14:23:42
Message-ID: 25573.1176215022@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> 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 released enough resources
>> for one waiting process to claim. i.e. there is a thundering herd
>> wakeup situation which destroys performance at high loads. Fixing
>> this will involve replacing the wakeup() calls with appropriate
>> amounts of wakeup_one().

> I'm forwarding this to the pgsql-hackers list so that folks more
> qualified than I can comment, but as I understand the way postgres
> implements locking each process has it *own* semaphore it waits on -
> and who is waiting for what is controlled by an in (shared) memory hash
> of lock structs (access to these is controlled via platform Dependant
> spinlock code). So a given semaphore state change should only involve
> one process wakeup.

Correct. The behavior Kris describes is surely bad, but it's not
relevant to Postgres' usage of SysV semaphores.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikolay Samokhvalov 2007-04-10 14:25:16 Re: "select ('{}'::text[])[1]" returns NULL -- is it correct?
Previous Message Tom Lane 2007-04-10 14:14:50 Idle idea for a feature