On 24 November 2010 01:11, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> 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. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
