Received: from sss.pgh.pa.us (sss.pgh.pa.us [209.114.132.154]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f03675742362; Wed, 3 Jan 2001 01:07:05 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.1/8.11.1) with ESMTP id f0367GB15335; Wed, 3 Jan 2001 01:07:16 -0500 (EST) To: Tom Samplonius cc: mlw , PostgreSQL-development , PostgreSQL-interfaces Subject: Re: [INTERFACES] Re: PHP and PostgreSQL In-reply-to: References: Comments: In-reply-to Tom Samplonius message dated "Tue, 02 Jan 2001 20:32:03 -0800" Date: Wed, 03 Jan 2001 01:07:16 -0500 Message-ID: <15332.978502036@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200101/48 X-Sequence-Number: 2720 Tom Samplonius writes: > ... Besides, as already has been tested, session startup time is > minimal. Well, mumble ... I think the startup time is negligible if you are issuing a reasonable number of queries per session (say a few dozen). But if you connect, issue one query, and disconnect, then undoubtedly you will find that performance sucks. We could probably do more to improve this situation on the server side, but IMHO it makes most sense to address the issue on the client side via connection reuse. The main reason for this is that a significant amount of the startup time for a standard connection consists of authentication overhead and context setup overhead (such as setting the timezone and character set encoding that the client wants to use). A general-purpose connection-reuse facility on the server end cannot eliminate these overheads, whereas it's trivial to avoid them within the context of a multi-threaded client. Bottom line: better to solve it by fixing Apache or PHP. regards, tom lane