Re: Persistent connections and transactions

On Thu, Jan 25, 2001 at 11:18:49AM -0300, Martin A. Marques wrote: [ . . . ] > No, and thats why in the postgres list we talked about persistent connections > not having much benefits. That is because the connection is persistent to the > httpd child that called it and not to all. Well, yes, but as long as the child lives, it'll be connected which means that every subsequent request to this child involving a database connection won't have to suffer the connection startup cost. If you have a rather inexpensive query, and a lot of web apps use simple, straightforward selects that are very inexpensive, then the connection startup overhead contributes more to the performance hit than the actual query. [ . . . ] > Now be carefull. http connection open and close, they do not stay open, so if > you try to execute different SQL statments with different httpd connections, > your gonna have trouble (the sql server won't let you, because there is > another transaction been executed). Hmm. Say the Apache child is idle (under which cirumstances exactly does it consider itself 'idle'?), receives a request for a page which executes a query (because it contains php code that does). This takes a while. In the meantime, while the SQL server is chugging away running the query, will the Apache child not accept further http requests? How does the Apache child know that it is waiting for the query to complete? This is what I don't know about the mechanism. Regards, Frank