Re: Admission Control Policy

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

In response to

Responses

Browse pgsql-hackers by date

  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)