Re: Interesting slow query

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Interesting slow query
Дата
Msg-id 13392.1150152788@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Interesting slow query  (PFC <lists@peufeu.com>)
Ответы Re: Interesting slow query  (PFC <lists@peufeu.com>)
Список pgsql-performance
PFC <lists@peufeu.com> writes:
>     Here are two ways to phrase a query... the planner choses very different
> plans as you will see. Everything is freshly ANALYZEd.

Usually we get complaints the other way around (that the NOT EXISTS
approach is a lot slower).  You did not show any statistics, but I
suspect the key point here is that the condition id > 1130306 excludes
most or all of the A and D tables.  The planner is not smart about
making transitive inequality deductions, but you could help it along
by adding the implied clauses yourself:

EXPLAIN ANALYZE SELECT r.* FROM raw_annonces r
  LEFT JOIN annonces a ON (a.id=r.id AND a.id > 1130306)
  LEFT JOIN archive_data d ON (d.id=r.id AND d.id > 1130306)
  WHERE a.id IS NULL AND d.id IS NULL AND r.id > 1130306
  order by id limit 1;

Whether this is worth doing in your app depends on how often you do
searches at the end of the ID range ...

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: PFC
Дата:
Сообщение: Interesting slow query
Следующее
От: Anthony Presley
Дата:
Сообщение: 64-bit vs 32-bit performance ... backwards?