Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id B50CE9FBB91 for ; Fri, 12 Oct 2007 04:38:51 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 14917-06 for ; Fri, 12 Oct 2007 04:38:07 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from flame.co.za (sharon.co.za [160.124.170.1]) by postgresql.org (Postfix) with ESMTP id 0B90C9FBC2C for ; Fri, 12 Oct 2007 04:38:09 -0300 (ADT) Received: from [192.168.0.161] (unknown [196.209.202.75]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by flame.co.za (Postfix) with ESMTP id 5A696803F5 for ; Fri, 12 Oct 2007 09:38:05 +0200 (SAST) Subject: Re: Performance problems with prepared statements From: Theo Kramer Reply-To: theo@flame.co.za To: pgsql-performance@postgresql.org In-Reply-To: References: <1192027540.2495.3.camel@localhost.localdomain> <470CE918.4060608@dalibo.com> <1192044840.2549.21.camel@fedmac> <470DE90E.2060605@archonet.com> <1192098798.2507.26.camel@localhost.localdomain> Content-Type: text/plain Organization: Flame Computing Enterprises cc Date: Fri, 12 Oct 2007 09:38:01 +0200 Message-Id: <1192174681.2470.12.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-4.fc7) Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200710/143 X-Sequence-Number: 27165 On Thu, 2007-10-11 at 13:28 -0400, Merlin Moncure wrote: > On 10/11/07, Theo Kramer wrote: > > On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote: > > > Theo Kramer wrote: > > > > > > > > So I suspect that there is something more fundamental here... > > > > > > OK, so there must be something different between the two scenarios. It > > > can only be one of: > > > 1. Query > > > 2. DB Environment (user, locale, settings) > > > 3. Network environment (server/client/network activity etc) > > > > I suspect that it could also be in the way the libpq PQprepare(), and > > PQexecPrepared() are handled... as opposed to the way PREPARE and > > EXECUTE are handled. > > PQexecPrepared is generally the fastest way to run queries from a C > app as long as you get the right plan. Some suggestions > > * you can explain/explain analyze executing prepared statements from > psql shell...try that and see if you can reproduce results Did that - see previous emails in this thread. > * at worst case you can drop to execParams which is faster (and > better) than PQexec, at least Thanks - will keep that option open. > * if problem is plan related, you can always disable certain plan > types (seqscan), prepare, and re-enable those plan types > * do as Jonah suggested, first step is to try and reproduce problem from psql No success on that. -- Regards Theo