Dimitri Fontaine <dfonta...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
