Re: Pooling in Core WAS: Need help in performance tuning. - Mailing list pgsql-performance

From Hannu Krosing
Subject Re: Pooling in Core WAS: Need help in performance tuning.
Date
Msg-id 1279828566.14271.16.camel@hvost
Whole thread Raw
In response to Re: Pooling in Core WAS: Need help in performance tuning.  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Pooling in Core WAS: Need help in performance tuning.
Re: Pooling in Core WAS: Need help in performance tuning.
List pgsql-performance
On Thu, 2010-07-22 at 12:15 -0700, Joshua D. Drake wrote:
> On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
> > On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
> > <craig@postnewspapers.com.au> wrote:
> > > So rather than asking "should core have a connection pool" perhaps
> > > what's needed is to ask "what can an in-core pool do that an external
> > > pool cannot do?"
> >
> > Avoid sending every connection through an extra hop.
>
> Let's extend this shall we:
>
> Avoid adding yet another network hop

postgreSQL is multi-process, so you either have a separate "pooler
process" or need to put pooler functionality in postmaster, bothw ways
you still have a two-hop scenario for connect. you may be able to pass
the socket to child process and also keep it, but doing this for both
client and db sides seems really convoluted.

Or is there a prortable way to pass sockets back and forth between
parent and child processes ?

If so, then pgbouncer could use it as well.

> Remove of a point of failure

rather move the point of failure from external pooler to internal
pooler ;)

> Reduction of administrative overhead

Possibly. But once you start actually using it, you still need to
configure and monitor it and do other administrator-y tasks.

> Integration into our core authentication mechanisms

True, although for example having SSL on client side connection will be
so slow that it hides any performance gains from pooling, at least for
short-lived connections.

> Greater flexibility in connection control

Yes, poolers can be much more flexible than default postgresql. See for
example pgbouncers PAUSE , RECONFIGURE and RESUME commands

> And, having connection pooling in core does not eliminate the use of an
> external pool where it makes since.

Probably the easiest way to achieve "pooling in core" would be adding an
option to start pgbouncer under postmaster control.

You probably can't get much leaner than pgbouncer.

> --
> PostgreSQL.org Major Contributor
> Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
> Consulting, Training, Support, Custom Development, Engineering
> http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt
>
>
>


--
Hannu Krosing   http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
   Services, Consulting and Training



pgsql-performance by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Next
From: Scott Carey
Date:
Subject: Re: Pooling in Core WAS: Need help in performance tuning.