"[EMAIL PROTECTED] (Nick Barr)" stated in comp.databases.postgresql.performance:Beware that persistent connections in PHP behave a little differently than you would think. The connections stays open between an apache process and postgres. So each process has its own connection and you may not hit the same process on each request to the apache server. Temporary tables are not dropped automatically between refreshes on persistent connections. An example of this is to enable persistent connections and execute "CREATE TEMPORARY TABLE foo ( id INTEGER );"
[EMAIL PROTECTED] wrote:[sNip]
Sorry I m a little bit confused about the persistent thing!!Use the persistent connection but make sure the parameters in postgresql.conf match up with the Apache config. The specific settings are MaxClients in httpd.conf and max_connections in postgresql.conf. Make sure that max_connections is at least as big as MaxClients for every database that your PHP scripts connect to.
Is it smart to use persistent connections at all if i expect 100K Users to hit the script in an hour and the script calls up to 10-15 pg functions?
I have at the mom one function but the server needs 500 ms, its a little bit too much i think, and it crashed when i had 20K users
Do you happen to have (or know where to get) some sample configuration files for Apache 2 and PostgreSQL for this? The documentation I've found so far is pretty sparse, and sample files would be very helpful.
$conn = pg_pconnect( ... );
if (!$result = pg_query($conn, "CREATE TEMPORARY TABLE tmp_foo ( id INTEGER );")) {
echo pg_result_error($result) ;
} else {
echo "created ok!";
}
After a couple of refreshes you will get an error that states the table already exists. This was a pain to learn, especially while I was doing these operations inside of transactions.
On most of my servers the connect time for postgresql was 6ms or less, so I disabled persistent connections altogether so that I could be assured that temporary tables and all php launched postgresql sessions were properly reset.
As far as I know, there is no way to reset the sesssion ( cleaning up temporary tables, etc ) automatically with an SQL statement without closing the connection
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
