Re: Admission Control Policy - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Admission Control Policy
Date
Msg-id 4B38E6CD020000250002D9CE@gw.wicourts.gov
Whole thread Raw
In response to Re: Admission Control Policy  (Dimitri Fontaine <dfontaine@hi-media.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Next
From: Jeff Davis
Date:
Subject: Re: Serializable implementation