| 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: | Whole Thread | Raw Message | 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. |