Skip site navigation (1) Skip section navigation (2)

Re: Prepared statements, parameters and logging

From: Csaba Nagy <nagy(at)ecircle-ag(dot)com>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, Postgres JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Prepared statements, parameters and logging
Date: 2007-06-26 08:22:25
Message-ID: 1182846145.13328.95.camel@coppola.muc.ecircle.de (view raw or flat)
Thread:
Lists: pgsql-jdbc
On Mon, 2007-06-25 at 23:40, Oliver Jowett wrote:
> I believe that's logging execution of an unnamed portal, not an unnamed 
> statement. I'm not sure whether the current server logging actually lets 
> you tell whether a named statement was used/reused or not (at least that 
> was one of my complaints about early versions of it -- haven't checked 
> what current versions do).
> 
> If the statement name is logged, it'd be something like "S_12345".

Thanks Oliver for your answer.

My real question is: am I turning the right knob with
"prepareThreshold=0" ? I want all queries to be planned taking into
account the parameter values by default. I can turn this off on special
cases by setting the prepare threashold on the statement level - if the
prepareThreshold is affecting at all the fact that parameters are sent
for planning or not... is it ?

I was supposing it is, but I could not figure it out from the logging -
and the results in query execution time seem to contradict what I get by
explain on a PREPARE (which suck the same as my production system) vs.
on direct sql with parameters included (which seems to yield the correct
plan). The actual case is a query including a table which has one id
value which has very skewed cardinality compared to the average, and the
generic plan sucks badly for this one id.

Thanks,
Csaba.



In response to

Responses

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2007-06-26 09:10:58
Subject: Re: Prepared statements, parameters and logging
Previous:From: Oliver JowettDate: 2007-06-25 22:07:44
Subject: Re: Prepared statements, parameters and logging

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group