2007/9/8, Denis Gasparin <denis@edistar.com>:
>
> > This has certainly been discussed before.
> >
> > IIRC the real argument against that was, that fork() isn't the most
> > expensive thing to do anymore. And Postgres does lots of other stuff
> > after accept(), namely connecting to a certain database,
> > authenticating the user, etc..
> Ok. I knew that. I made the question because it seems that, for example,
> Oracle in release 11g is moving to a similar solution in order to solve
> connection pooling problems.
>
> For example look at the following link:
>
> http://pbarut.blogspot.com/2007/08/oracle-11g-drcp-database-resident.html
>
sure... regarding Oracle, it's different story because of their
development model which is not opensource and has to rely on own
solutions instead of following unix tradition of modularity.
regarding Apache, it's different story because HTTP is stateless
protocol! which enables random backend switching, in contrary to
postgres backend protocol.
Anyway, stateless connection pooling is already implemented (pgpool/pgbouncer/?)
Stateful connection pooling is hard to implement without rewriting the
protocol itself or disrupting existing behaviour.
--
Filip Rembiałkowski