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

From Thomas Burdairon
Subject Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
Date
Msg-id 7A8B09D5-96E7-44E1-8306-3B3425792AC6@entelience.com
Whole thread Raw
In response to Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-jdbc
On 10 avr. 08, at 12:44, Dave Cramer wrote:
> It's pretty easy to test.
>
> prepare the query
> and
> run explain analyze on the prepared statement.
>
> Dave
>
Thank you Dave for your answer, this helped me to find the problem.

1 - it's not a JDBC related problem (sorry for the noise) as i could
reproduce it within psql

2 - Comparing query plans between the prepared and unprepared queries
helped me to find a useless INNER JOIN in the query. Removing it made
the query much faster and I don't have the problem anymore.

3 - The problem was coming from my query (sorry for the noise, again).

Problem solved, at least for me.
Thanks again


Now, i'm still wondering if there could be a planner problem, because
the prepared query was running 10times slower than the unprepared
one. Or maybe a bad configuration on my side

Just for the story here are the different plans :

The prepared query :
http://rafb.net/p/Tn9g6X27.html

the same, unprepared :
http://rafb.net/p/lutugN55.html

the prepared query, fixed :
http://rafb.net/p/HmHetm36.html




pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
Next
From: Art Gramlich
Date:
Subject: Re: Patch to add a socketTimeout property.