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