> Right, let's not confuse Kevin's argument that we should have
> connection pooling in core with advocacy for any particular patch or
> feature suggestion that he may have offered on some other thread. A
> very simple in-core connection pooler might look something like this:
> when a session terminates, the backend doesn't exit. Instead, it
> waits for the postmaster to reassign it to a new connection, which the
> postmaster does in preference to starting new backends when possible.
> But if a backend doesn't get assigned a new connection within a
> certain period of time, then it goes ahead and exits anyway.
This would, in my opinion, be an excellent option for PostgreSQL and
would save a LOT of newbie pain. Going back to my list, it would help
with both problems (a) and (c). It wouldn't be as good as pgbouncer,
but it would be "good enough" for a lot of users.
HOWEVER, there is the issue that such a mechanism isn't "free". There
are issue with sharing backends around GUCs, user configuration,
security, and prepared plans -- all issues which presently cause people
difficulty with pgbouncer. I think the costs are worth it, but we'd
have to make some attempt to tackle those issues as well. And, of
course, we'd need to let DBAs turn the pooling off.
I'd envision parameters:
pool_connections true/false
pool_connection_timeout 60s
> I'm also relying on the unsubstantiated assumption that it's
> possible to pass a socket connection between processes.
Doesn't pgpool do this?
> Still another approach is admission control based on transactions,
> backends, queries, memory usage, I/O, or what have you.
That's a different problem, and on its own doesn't help newbies. It's
complimetary to pooling, though, so would be nice to have.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
