Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
От | Thomas Burdairon |
---|---|
Тема | Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work |
Дата | |
Msg-id | 7A8B09D5-96E7-44E1-8306-3B3425792AC6@entelience.com обсуждение исходный текст |
Ответ на | Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work (Dave Cramer <pg@fastcrypt.com>) |
Список | 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 по дате отправления: