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: (view raw, whole thread or download thread mbox)
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.


In response to


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-2017 The PostgreSQL Global Development Group