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

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

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: 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
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Date: 2010-07-23 16:52:37
Message-ID: 1279903957.22360.190.camel@jd-desktop.unknown.charter.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, 2010-07-22 at 20:56 +0100, Hannu Krosing wrote:
>  
> > 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. 

Which means, right now there is three hops. Reducing one is good.

> 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 ;)

Yes but at that point, it doesn't matter. 

> 
> > 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.

Yes, but it is inclusive.

> 
> > 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.

Yes, but right now you can't use *any* pooler with LDAP for example. We
could if pooling was in core. Your SSL argument doesn't really work
because its true with or without pooling.

> > Greater flexibility in connection control
> 
> Yes, poolers can be much more flexible than default postgresql. See for
> example pgbouncers PAUSE , RECONFIGURE and RESUME commands 

:D

> 
> > 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.

Yeah but that won't happen. Also I think we may have a libevent
dependency that we have to work out.

> 
> You probably can't get much leaner than pgbouncer.

Oh don't get me wrong. I love pgbouncer. It is my recommended pooler but
even it has limitations (such as auth).

Sincerely,

Joshua D. Drake

-- 
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


In response to

Responses

pgsql-performance by date

Next:From: Robert HaasDate: 2010-07-23 17:28:53
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Previous:From: Hannu KrosingDate: 2010-07-23 15:58:27
Subject: Re: Pooling in Core WAS: Need help in performance tuning.

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