From: | Hannu Krosing <hannu(at)2ndquadrant(dot)com> |
---|---|
To: | jd(at)commandprompt(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-22 19:56:06 |
Message-ID: | 1279828566.14271.16.camel@hvost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)postnewspapers(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2010-07-22 21:29:54 | Re: Pooling in Core WAS: Need help in performance tuning. |
Previous Message | Hannu Krosing | 2010-07-22 19:15:44 | Re: Pooling in Core WAS: Need help in performance tuning. |