Skip site navigation (1) Skip section navigation (2)

Re: Pooling in Core WAS: Need help in performance tuning.

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "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 06:36:19
Message-ID: 4C4A89E3.5040607@postnewspapers.com.au (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: Yeb HavingaDate: 2010-07-24 07:20:50
Subject: Testing Sandforce SSD
Previous:From: Gerald FontenayDate: 2010-07-24 06:29:37
Subject: Re: Strange explain on partitioned tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group