2007/9/8, Denis Gasparin <denis@xxxxxxxxxxx>:>> > 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 theirdevelopment model which is not opensource and has to rely on ownsolutions instead of following unix tradition of modularity. regarding Apache, it's different story because HTTP is statelessprotocol! which enables random backend switching, in contrary topostgres backend protocol. Anyway, stateless connection pooling is already implemented (pgpool/pgbouncer/?) Stateful connection pooling is hard to implement without rewriting theprotocol itself or disrupting existing behaviour. -- Filip Rembiałkowski ---------------------------(end of broadcast)---------------------------TIP 6: explain analyze is your friend
