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...
In response to
pgsql-hackers by date
|Next:||From: Kevin Grittner||Date: 2009-12-28 22:56:34|
|Subject: Re: Admission Control Policy|
|Previous:||From: Andres Freund||Date: 2009-12-28 22:54:51|
|Subject: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)|