From: Greg Smith <greg@2ndquadrant.com>
To: Jesper Krogh <jesper@krogh.cc>
Cc: Matthew Wakeling <matthew@flymine.org>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Brad Nicholson <bnichols@ca.afilias.info>
Cc: pgsql-performance@postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Need help in performance tuning.
Date: Sat, 10 Jul 2010 13:30:21 +0100
Message-ID: <4C3867DD.1020004@2ndquadrant.com> (raw)
In-Reply-To: <4C38143C.3080304@krogh.cc>
References: <AANLkTiknhZhKtGDidBsMWtPJpRgln9DrrsCebCEYk5XE@mail.gmail.com>
<4C369346.6010501@postnewspapers.com.au>
<AANLkTin4Q4APRnbJ85FRasU7n8LuhKibKYcGnexsEbTt@mail.gmail.com>
<8760.1278650566@sss.pgh.pa.us>
<1278680186.1914.36.camel@bnicholson-desktop>
<4C36F57102000025000332F6@gw.wicourts.gov>
<alpine.DEB.2.00.1007091621380.2534@aragorn.flymine.org>
<4C36FEAD02000025000332FC@gw.wicourts.gov>
<alpine.DEB.2.00.1007091753350.2534@aragorn.flymine.org>
<4C37A9C1.1060405@2ndquadrant.com>
<4C38143C.3080304@krogh.cc>
Jesper Krogh wrote:
> I dont think a build-in connection-poller (or similiar) would in any
> way limit the actions and abillities of an external one?
Two problems to recognize. First is that building something in has the
potential to significantly limit use and therefore advancement of work
on external pools, because of the "let's use the built in one instead of
installing something extra" mentality. I'd rather have a great external
project (which is what we have with pgBouncer) than a mediocre built-in
one that becomes the preferred way just by nature of being in the core.
If work on a core pooler was started right now, it would be years before
that reached feature/performance parity, and during that time its
existence would be a net loss compared to the current status quo for
many who used it.
The second problem is the limited amount of resources to work on
improvements to PostgreSQL. If you want to improve the reach of
PostgreSQL, I consider projects like materialized views and easy
built-in partitioning to be orders of magnitude more useful things to
work on than the marginal benefit of merging the features of the
external pool software inside the database. I consider the whole topic
a bit of a distraction compared to instead working on *any* of the
highly rated ideas at http://postgresql.uservoice.com/forums/21853-general
As a random technical note, I would recommend that anyone who is
thinking about a pooler in core take a look at how pgBouncer uses
libevent to respond to requests, a design model inspired by that of
memcached. I haven't looked at it deeply yet, but my gut guess is that
this proven successful model would be hard to graft on top of the
existing PostgreSQL process design, and doing anything but that is
unlikely to perform as well.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: greg@2ndquadrant.com, jesper@krogh.cc, matthew@flymine.org, Kevin.Grittner@wicourts.gov, bnichols@ca.afilias.info, tgl@sss.pgh.pa.us
Subject: Re: Need help in performance tuning.
In-Reply-To: <4C3867DD.1020004@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox