From: | Thomas Burdairon <tburdairon(at)entelience(dot)com> |
---|---|
To: | Dave Cramer <pg(at)fastcrypt(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work |
Date: | 2008-04-10 12:33:39 |
Message-ID: | 7A8B09D5-96E7-44E1-8306-3B3425792AC6@entelience.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers 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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-04-10 12:46:08 | Re: Commit fest queue |
Previous Message | Heikki Linnakangas | 2008-04-10 12:05:31 | Re: Free Space Map data structure |
From | Date | Subject | |
---|---|---|---|
Next Message | Art Gramlich | 2008-04-10 16:50:55 | Re: Patch to add a socketTimeout property. |
Previous Message | Dave Cramer | 2008-04-10 10:44:20 | Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work |