Re: profiling connection overhead

> * no coordination of restarts/configuration changes between the cluster
> and the pooler
> * you have two pieces of config files to configure your pooling settings
> (having all that available say in a catalog in pg would be awesome)
> * you lose all of the advanced authentication features of pg (because
> all connections need to go through the pooler) and also ip-based stuff
> * no SSL support(in the case of pgbouncer)
> * complexity in reseting backend state (we added some support for that
> through explicit SQL level commands in recent releases but it still is a
> hazard)

More:

* pooler logs to separate file, for which there are (currently) no
anaysis tools
* pooling is incompatible with the use of ROLES for data security

The last is a major issue, and not one I think we can easily resolve.
MySQL has a pooling-friendly user system, because when you connect to
MySQL you basically always connect as the superuser and on connection it
switches you to your chosen login role. This, per Rob Wulsch, is one of
the things at the heart of allowing MySQL to support 100,000 low
frequency users per cheap hosting system.

As you might imagine, this behavior is also the source of a lot of
MySQL's security bugs. I don't see how we could imitate it without
getting the bugs as well.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com