From: Craig Ringer <craig@postnewspapers.com.au>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Date: Sat, 24 Jul 2010 14:36:19 +0800
Message-ID: <4C4A89E3.5040607@postnewspapers.com.au> (raw)
In-Reply-To: <4C4A78BC.2020101@2ndquadrant.com>
References: <4C37791C0200002500033379@gw.wicourts.gov>
<4C37CBFB.1000800@agliodbs.com>
<4C37EA1D.6000008@postnewspapers.com.au>
<AANLkTimNJZlX7kFH_r0-BB_K3NGorU7BHd85SxXJbuGJ@mail.gmail.com>
<4C38BF03.6060503@agliodbs.com>
<19244.1278787866@sss.pgh.pa.us>
<alpine.DEB.2.00.1007121044330.2534@aragorn.flymine.org>
<4C3AF564.5030204@postnewspapers.com.au>
<AANLkTinDgkzqf_=O+hk5OMq+AxN4G+fpfQZM4DBizAOF@mail.gmail.com>
<82DAA0BC-52E8-4279-81DF-14373755A42F@richrelevance.com>
<4c49bb81.17bb720a.42c2.1de8@mx.google.com>
<4C4A78BC.2020101@2ndquadrant.com>
On 24/07/10 13:23, 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.
Putting a pooler in core won't inherently fix this, and won't remove the
need to solve it for cases where the pooler can't be on the same machine.
9.0 has application_name to let apps identify themselves. Perhaps a
"pooled_client_ip", to be set by a pooler rather than the app, could be
added to address this problem in a way that can be used by all poolers
new and existing, not just any new in-core pooling system.
If a privileged set of pooler functions is was considered, as per my
other recent mail, the pooler could use a management connection to set
the client ip before handing the connection to the client, so the client
couldn't change pooled_client_ip its self by accident or through malice.
But even without that, it'd be awfully handy.
--
Craig Ringer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig@postnewspapers.com.au, greg@2ndquadrant.com, robertmhaas@gmail.com
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
In-Reply-To: <4C4A89E3.5040607@postnewspapers.com.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox