DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=t1L8suK0XXCSg7dyvoJlU3zIKKCqgL8R26FfDXG7sy9fDj14zxT1PK4umjxgVGlK9KJf9ZjA5+GmAk/FpXaubfrAObdrSz/mY4EHc3lX/5SnvSchWC4XIk+P6+stsXJpHKyK9RbaPfYCEbdh6JsD1TKe/SnYmeCjWTZ0Mmosb14=
Message-ID: <b42b73150710111028h51a6798agf862e5e88cbc123c@mail.gmail.com>
Date: Thu, 11 Oct 2007 13:28:51 -0400
From: "Merlin Moncure" <mmoncure@gmail.com>
To: theo@flame.co.za
Subject: Re: Performance problems with prepared statements
Cc: pgsql-performance@postgresql.org
In-Reply-To: <1192098798.2507.26.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

On 10/11/07, Theo Kramer <theo@flame.co.za> 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
* at worst case you can drop to execParams which is faster (and
better) than PQexec, at least
* 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

merlin