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 по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: Re: [HACKERS] How embarrassing: optimization of a one-shot query doesn't work
Следующее
От: Art Gramlich
Дата:
Сообщение: Re: Patch to add a socketTimeout property.