Dimitri Fontaine <dfonta...@hi-media.com> wrote: > No, in session pooling you get the same backend connection for the > entire pgbouncer connection, it's a 1-1 mapping. Right -- so it doesn't allow more logical connections than that with a limit to how many are active at any one time, *unless* the clients cooperate by closing the connections between transactions -- effectively requiring a client "yield" to accomplish what an ACP could do without special client cooperation. >> Well, I don't know that you can very accurately predict a plan or >> what its memory usage would be. Trying to work out all >> permutations in advance and send each query to the right pool >> doesn't seem workable on a large scale. > > True. I was just trying to see what components we already have, > while you're explaining what's missing: teamwork? :) It would take a lot more than teamwork to accurately predict those things. Particularly in an environment with a large number of dynamically generated queries. > pushing what we already have to their limits is often a nice way > to describe what we want but still don't have... Sure, and I'm a big fan of building things from proven smaller pieces where possible. Like with Linux utilities (grep, sed, awk, find, xargs). I just think that in this case a connection pool is complementary and doesn't fit into the solution to these particular problems very well. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
