Message-ID: <470DE90E.2060605@archonet.com>
Date: Thu, 11 Oct 2007 10:12:46 +0100
From: Richard Huxton <dev@archonet.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20070728)
MIME-Version: 1.0
To: theo@flame.co.za
CC: pgsql-performance@postgresql.org
Subject: Re: Performance problems with prepared statements
References: <1192027540.2495.3.camel@localhost.localdomain>	
	<470CE918.4060608@dalibo.com> <1192044840.2549.21.camel@fedmac>
In-Reply-To: <1192044840.2549.21.camel@fedmac>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Theo Kramer wrote:
> Thanks, had missed that, however, I am afraid that I fail to see how
> preparing a query using PQprepare() and then executing it using
> PQexecPrepared(), is 8 thousand times slower than directly executing
> it.,, ( 403386.583ms/50.0ms =  8067 ).
> 
> When doing a 'manual' prepare and explain analyze I get the following

> rascal=# explain analyze execute cq ('124         ', 8, 366942);
>  Total runtime: 3.272 ms
> 
> 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)

Are you sure you have the parameter types correct in your long-running 
query?
Try setting log_min_duration_statement=9000 or so to capture 
long-running queries.

Make sure the user and any custom settings are the same. Compare SHOW 
ALL for both ways.

You've said elsewhere you've ruled out the network environment, so 
there's not point worrying about that further.

-- 
   Richard Huxton
   Archonet Ltd