Dimitri Fontaine <dfontaine(at)hi-media(dot)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