On 24 November 2010 01:11, Craig Ringer <craig@postnewspapers.com.au> wrote:
> On 11/22/2010 11:38 PM, Ivan Voras wrote:
>> It looks like a hack (and one which is already implemented by connection
>> pool software); the underlying problem should be addressed.
>
> My (poor) understanding is that addressing the underlying problem would
> require a massive restructure of postgresql to separate "connection and
> session state" from "executor and backend". Idle connections wouldn't
> require a backend to sit around unused but participating in all-backends
> synchronization and signalling. Active connections over a configured maximum
> concurrency limit would queue for access to a backend rather than fighting
> it out for resources at the OS level.
>
> The trouble is that this would be an *enormous* rewrite of the codebase, and
> would still only solve part of the problem. See the prior discussion on
> in-server connection pooling and admission control.
I'm (also) not a PostgreSQL developer so I'm hoping that someone who
is will join the thread, but speaking generally, there is no reason
why this couldn't be a simpler problem which just requires
finer-grained locking or smarter semaphore usage.
I'm not talking about forcing performance out of situation where there
are no more CPU cycles to take, but about degrading gracefully in
those circumstances and not taking a 80%+ drop because of spinning
around in semaphore syscalls.
