Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work - Mailing list pgsql-jdbc

From PFC
Subject Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
Date
Msg-id op.t8xsjkmscigqcu@apollo13.peufeu.com
Whole thread Raw
In response to Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-jdbc
On Tue, 01 Apr 2008 16:06:01 +0200, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Dave Cramer <pg@fastcrypt.com> writes:
>> Was the driver ever changed to take advantage of the above strategy?
>
> Well, it's automatic as long as you use the unnamed statement.  About
> all that might need to be done on the client side is to use unnamed
> statements more often in preference to named ones, and I believe that
> something like that did get done in JDBC.
>
>             regards, tom lane
>

PHP is also affected if you use pg_query_params...
Syntax : pg_query_params( "SQL with $ params", array( parameters )

Note that value is TEXT, indexed, there are 100K rows in table.

pg_query( "SELECT * FROM test WHERE id =12345" ); 1 rows in
0.15931844711304 ms
pg_query( "SELECT * FROM test WHERE value LIKE '1234%'" ); 11 rows in
0.26795864105225 ms

pg_query_params( "SELECT * FROM test WHERE id =$1", array( 12345 ) ); 1
rows in 0.16618013381958 ms
pg_query_params( "SELECT * FROM test WHERE value LIKE $1", array( '1234%'
)); 11 rows in 40.66633939743 ms

Last query does not use index.
However since noone uses pg_query_params in PHP (since PHP coders just
LOVE to manually escape their strings, or worse use magicquotes), noone
should notice ;)

pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
Next
From: Kris Jurka
Date:
Subject: Re: CallableStatement and getUpdateCount