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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Matthew Wakeling" <matthew(at)flymine(dot)org>, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Pooling in Core WAS: Need help in performance tuning.
Date: 2010-07-12 12:41:36
Message-ID: 4C3AC73002000025000333ED@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

(1) It can prevent the most pessimal performance problems resulting
from lack of an external connection pool (or a badly configured one)
by setting a single GUC. Configuration tools could suggest a good
value during initial setup.

(2) It can be used without installing and configuring a more
sophisticated and complex product.

(3) It might reduce latency because it avoids having to receive,
parse, and resend data in both directions -- eliminating one "hop".
I know the performance benefit would usually accrue to the external
connection pooler, but there might be some circumstances where a
built-in pool could win.

(4) It's one more checkbox which can be ticked off on some RFPs.

That said, I fully agree that if we can include good documentation
on the external poolers and we can get packagers to include poolers
in their distribution, that gets us a much bigger benefit. A
built-in solution would only be worthwhile if it was simple enough
and lightweight enough not to be a burden on execution time or
maintenance. Maybe that's too big an if.

-Kevin

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Rob Wultsch 2010-07-12 13:11:31 Re: now() gives same time within the session
Previous Message Kevin Grittner 2010-07-12 12:28:40 Re: PostgreSQL PITR - more doubts