On 2010-07-10 00:59, Greg Smith wrote:
Matthew Wakeling wrote:
> If you have an external pool solution, you can put it somewhere
> else - maybe on multiple somewhere elses.
This is the key point to observe: if you're at the point where you
have so many connections that you need a pool, the last place you
want to put that is on the overloaded database server itself.
Therefore, it must be an external piece of software to be effective,
rather than being part of the server itself. Database servers are
relatively expensive computing hardware due to size/quantity/quality
of disks required. You can throw a pooler (or poolers) on any cheap
1U server. This is why a built-in pooler, while interesting, is not
particularly functional for how people normally scale up real-world
deployments.
That may be totally correct for the 10% of the userbase
that are in a squeezed situation, but for the 90% that isn't (or isn't aware
of being there), the build-in would be a direct benefit. For the 20%
living near the "edge" it may be the difference between "just working" and
extra hassle.
I think it is a fair assumption that the majority of PG's users solves
the problems without an connection pooler, and the question
is if it is beneficial to let them scale better without doing anything?
I have also provided a case where Kevin proposal "might" be a
benefit but a connection pooler cannot solve it:
http://archives.postgresql.org/pgsql-hackers/2010-06/msg01438.php
(at least as I see it, but I'm fully aware that there is stuff I dont
know of)
I dont think a build-in connection-poller (or similiar) would in any
way limit the actions and abillities of an external one?
* Both numbers wildly guessed..
--
Jesper
