Re: avoid prepared statements on complex queries? - Mailing list pgsql-jdbc

From Anish Kejariwal
Subject Re: avoid prepared statements on complex queries?
Date
Msg-id 1321491524.39608.YahooMailNeo@web33901.mail.mud.yahoo.com
Whole thread Raw
In response to Re: avoid prepared statements on complex queries?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-jdbc
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@sss.pgh.pa.us>
To: Kris Jurka <books@ejurka.com>
Cc: Maciek Sakrejda <msakrejda@truviso.com>; Anish Kejariwal <anishkej@yahoo.com>; "pgsql-jdbc@postgresql.org" <pgsql-jdbc@postgresql.org>
Sent: Wednesday, November 16, 2011 4:35 PM
Subject: Re: [JDBC] avoid prepared statements on complex queries?

Kris Jurka <books@ejurka.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


pgsql-jdbc by date:

Previous
From: Tom Lane
Date:
Subject: Re: avoid prepared statements on complex queries?
Next
From: Thomas Kellerer
Date:
Subject: Re: Encoding for error messages during connect