2007/9/8, Denis Gasparin <[EMAIL PROTECTED]>:
>
> > 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 datab
> 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
Hi,
Denis Gasparin wrote:
Why not to implement a connection pooling server side as apache for
example does?
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
afte
You'll want to evaluate pgBouncer to see if it meets your needs. It
works very well for general proxying, connection pooling.
On 9/7/07, Denis Gasparin <[EMAIL PROTECTED]> wrote:
> I'm looking for connection pooling solutions for our php/apache server.
>
> I already checked pgpool and pgbouncer b
On 07.09.2007 10:16, Denis Gasparin wrote:
What to do you think about this?
I think there is no need for this and it's the wrong place to implement it.
Why should PostgreSQL do something to work around broken application
design? An application that closes its database connection just to
crea
I'm looking for connection pooling solutions for our php/apache server.
I already checked pgpool and pgbouncer but during the tests, I had the
following (mad) idea...
Why not to implement a connection pooling server side as apache for
example does?
I try to explain my idea...
The postgres serve
