From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Joshua Tolley <eggyknap(at)gmail(dot)com>, Scott Carey <scott(at)richrelevance(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Matthew Wakeling <matthew(at)flymine(dot)org>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Pooling in Core WAS: Need help in performance tuning. |
Date: | 2010-07-24 05:32:22 |
Message-ID: | 20100724053222.GB22197@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, Jul 24, 2010 at 01:23:08AM -0400, Greg Smith wrote:
> Joshua Tolley wrote:
> >Relatively minor, but it would be convenient to avoid having to query
> >$external_pooler to determine the client_addr of an incoming connection.
>
> You suggest this as a minor concern, but I consider it to be one of
> the most compelling arguments in favor of in-core pooling. A
> constant pain with external poolers is the need to then combine two
> sources of data in order to track connections fully, which is
> something that everyone runs into eventually and finds annoying.
> It's one of the few things that doesn't go away no matter how much
> fiddling you do with pgBouncer, it's always getting in the way a
> bit. And it seems to seriously bother systems administrators and
> developers, not just the DBAs.
But you have to admit that this problem won't vanish as people will
continue to use poolers on other machines for resource reasons.
So providing a capability to do something sensible here seems to be
useful independent of in-core pooling.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2010-07-24 06:23:01 | Re: Pooling in Core WAS: Need help in performance tuning. |
Previous Message | Greg Smith | 2010-07-24 05:23:08 | Re: Pooling in Core WAS: Need help in performance tuning. |