Dimitri Fontaine <dfontaine@hi-media.com> wrote:
> Le 28 déc. 2009 à 21:33, Kevin Grittner a écrit :
>> We often see posts from people who have more active connections
>> than is efficient.
>
> How would your proposal better solve the problem than using
> pgbouncer?
With my current knowledge of pgbouncer I can't answer that
definitively; but *if* pgbouncer, when configured for transaction
pooling, can queue new transaction requests until a connection is
free, then the differences would be:
(1) According to pgbouncer documentation, transaction pooling is "a
hack as it breaks application expectations of backend connection.
You can use it only when application cooperates with such usage by
not using features that can break." This would not be an issue with
an ACP.
(2) For the "active connection" aspect of the policy, you could let
through superuser requests while other requests were queuing.
(3) With the ACP, the statements would be parsed and optimized
before queuing, so they would be "ready to execute" as soon as a
connection was freed.
(4) Other factors than active connection count could be applied,
like expected memory consumption, or more esoteric metrics.
In favor of pgbouncer (or other connection poolers) they don't
require the overhead of a process and connection for each idle
connection, so I would recommend a connection pooler even with an
ACP. They cover overlapping ground, but I see them as more
complementary than competing.
-Kevin