Re: Admission Control Policy
От | Kevin Grittner |
---|---|
Тема | Re: Admission Control Policy |
Дата | |
Msg-id | 4B38E6CD020000250002D9CE@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Admission Control Policy (Dimitri Fontaine <dfontaine@hi-media.com>) |
Список | pgsql-hackers |
Dimitri Fontaine <dfontaine@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
В списке pgsql-hackers по дате отправления: