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