Le 28 déc. 2009 à 23:35, Kevin Grittner a écrit : > So the application would need to open and close a pgbouncer > connection for each database transaction in order to share the > backend properly?
No, in session pooling you get the same backend connection for the entire pgbouncer connection, it's a 1-1 mapping. > 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? :) > If we had a pooler bundled into the backend and defaulted to a > halfway reasonable configuration, it's possible that implementing an > active connection limit the second tier ACP would be covering close > enough to the same ground as to be redundant. I'm not quite > convinced, however, that your proposed use of pgbouncer for this, > given the multiple pools which would need to be configured and the > possible application awareness and cooperation with policy would be > better than a fairly simple ACP. It seems a bit like driving nails > with a wrench. I like wrenches, I use them to turn things, but I > don't like using them to drive nails when I can help it. :-) Hehe, pushing what we already have to their limits is often a nice way to describe what we want but still don't have... I think... -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
