From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Admission Control Policy |
Date: | 2009-12-28 22:55:42 |
Message-ID: | EDC77ABA-8DC7-4405-9A8A-EEDDF38D99BB@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-12-28 22:56:34 | Re: Admission Control Policy |
Previous Message | Andres Freund | 2009-12-28 22:54:51 | Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb) |