Bruce Momjian writes:
> OK, let's assume we have pre-forked backends that do the accept(). One
> enhancement would be for the child to connect to the last requested
> database. If the accept() user wants the same database, it is already
> connected, or at least its cache is loaded. If they want another one,
> we can disconnect and connect to the database they request. This would
> be portable for all OS's because there is no file descriptor passing.
This is bad because you have hidden "connection pooling" that cannot be
circumvented, and I guarantee that it will become a problem because "new
connection" will no longer equal "new connection". Additionally, you're
assuming a setup were any new connection will connect to a random (from
the server's point of view) database. I claim these setups are not the
majority. In fact, any one client application would usually only connect
to exactly one database, so it might as well keep that connection open.
For systems were this is not possible for some reason or where different
databases or connection parameters are really required, there are already
plenty of solutions available that are tuned or tunable to the situation
at hand, so your solution would just get in the way. In short, you're
adding a level of complexity where there is no problem.
> Added to TODO:
I haven't seen a consensus yet.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
