Re: avoid prepared statements on complex queries?

Thanks Tom.  That's great to know this will be addressed in 9.2.

Btw - I turned logging on and verified that by setting by setting prepareThreshold the prepared statement became an unnamed statement.  This did not fix the performance issue I've been seeing.  I'm going to have to resort to constructing the query myself by building the query string....

thanks for everyones help.  

Anish

________________________________
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Maciek Sakrejda <msakrejda(at)truviso(dot)com>; Anish Kejariwal <anishkej(at)yahoo(dot)com>; "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Sent: Wednesday, November 16, 2011 4:35 PM
Subject: Re: [JDBC] avoid prepared statements on complex queries?

Kris Jurka <books(at)ejurka(dot)com> writes:
> On Wed, 16 Nov 2011, Maciek Sakrejda wrote:
>> Maybe, although I've never seen that happen and as I understand, the
>> driver always sends parameters along with the statement when using
>> unnamed statements, so I'm not sure what would trigger this.

> The standard example is "WHERE col LIKE ?".  If the parameter is something
> like 'abcdef%' then the query can potentially be converted to a range
> scan, but only if knows the parameter value.  When preparing this with an
> unnamed statement the server has the parameter value, but cannot assume
> that the same unnamed statement won't be used with a different parameter
> value later and must come up with a plan that is correct for all possible
> parameters even if it's not ideal for the current one.

BTW, this should be all better in 9.2 ... so if anyone is thinking of
expending lots of effort to fix it on the JDBC side, don't bother.

            regards, tom lane