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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2007-06-26 09:10:58 | Re: Prepared statements, parameters and logging |
Previous Message | Oliver Jowett | 2007-06-25 22:07:44 | Re: Prepared statements, parameters and logging |