On Mon, 28 Jan 2002, Frank Bax wrote:
> The connection will only be reused if the *same* apache child process
> handles the request. You should expect to see many postgres client
> connections.
> A) Each database/user connection combination.
> B) Each apache child process
>
> Multiply A*B to get max number of concurrent connections. If A*B can go
> over postgres connection limit, then you might start getting connection
> refused messages.
Are you sure? Doesn't the httpd child process close the active connection
if the database/username pair is different, before opening a new one?
On a db with say 10000 different users, the usage of pconnect() may
potentially lead to 10000 * B open connections (thus postgres backends),
most of those completely useless...
... some thinking ...
no, I was wrong:
pgsql.max_persistent integer
The maximum number of persistent Postgres connections per process.
^^^^^^^^^^^
you can have more than one persistent connection per httpd process. Now
that I think about it, it seems a good idea to limit it to some sane
value.
> If your postgres database is on the same server as you webserver, there is
> neglible gains for using pconnect over connect.
>
> Frank
Well, it depends on the type of queries. For *a lot* of very simple and
fast queries performed by the same user (like readonly selects in a single
user environment), the TCP connect and fork/exec (of the postgres backends)
overhead may dominate. Of course, whenever the query time dominates,
it makes hardly a difference.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx
