On Fri, May 27, 2011 at 6:22 AM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> wrote: > Best performance is often obtained with the number of _active_ connections > in the 10s to 30s on commonplace hardware. I'd want to use "hundreds" - > because mailing list posts etc suggest that people start running into > problems under load at the 400-500 mark, and more importantly because it's > well worth moving to pooling _way_ before that point. If you can. I'd love a connection pool that knows when I have a resource that persists across transactions like a cursor or temporary table and the backend connection needs to be maintained between transactions, or if there are no such resources and the backend connection can be released to the pool between transactions. I suspect this sort of pool would need to be built into the core. At the moment I only see a benefit with a pool from connections from my webapp which I know can safely go through pgbouncer in transaction pooling mode. Or would there be some way of detecting if the current session has access to stuff that persists across transactions and this feature could be added to the existing connection pools? -- Stuart Bishop <stuart@xxxxxxxxxxxxxxxx> http://www.stuartbishop.net/ -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
