Производительность запросов в PostgreSQL – шаг за шагом

[egaxegax]

Немного личных исследований производительности запросов http://egaxegax.appspot.com/posts/77004.

И еще насчет join'ов. Вместо стандартного вида

 select t1.d, t2.d, t3.d form t1,t2,t3 where t1.b=t2.a and t3.b=t2.a and t3.d=3;

можно написать так

select d as sm, zn, tm from t1,
    ( select a, d as zn, tm from t2,
      ( select b, d as tm from t3 where d=3 ) s
    where a=s.b ) s
where b=s.a

В этом случае выполнив отдельные подзапросы можно узнать сколько времени онb выполняются и так проанализировать все join'ы поштучно.

[Ivan22]

стандартный вид у вас не совсем стандартен. Я рекомендую анси.

[akzhan]

Кроме того, подозрительны запросы с большим OFFSET, обычные пользователи такие не делают, а стоимость их высока.

[ikovrigin]

Наверное я необычный пользователь, но если мне сказать что в данных 100500 страниц, мне обязательно будет интересно что там на последней и что там на 50200 :)…

[wildraid]

Кстати, произвольный offset без потери производительности возможен в PG.
https://www.depesz.com/2011/05/20/pagination-with-fixed-order/

Конечно, при помощи сложных ухищрений и со множеством ограничений. Но, если какой-то сервис крутится только вокруг pagination, это можно сделать.

[ikovrigin]

Ограничения слишком жесткие, у каждого пользователя может быть своя пагинация связанная например с ограничениями видимости или релевантностью.

[wildraid]

По опыту, если сложный запрос написан без очевидных ошибок, но план выполнения подозрительный, то первым делом смотрю разницу между estimated rows и actual rows. Часто дело именно в неверном предположении о количестве возвращаемых рядов, которое потом может кратно умножаться по мере продвижения по дереву.

[ikovrigin]

Да наверное это самая частая проблема и в то же время она же одна из самых нетривиальных, как убедить оптимизатор что он ошибся, а главное как заставить его сделать верные заключения. Т.е детекция данной проблемы это далеко еще не решение :(.

[romy4]

> Поэтому все программисты любят индексы
кроме symfony-стов :)

[VolCh]

Что не так?

[romy4]

Не любят они лезть в базу и создавать индексы. Если доктрина решила, что не надо, значит ей видней.

[VolCh]

Значит я какой-то неправильный симфонист. Другое дело, что не люблю создавать индексы средствами доктрины, а именно лезу в базу, если запросы тормозят.

[romy4]

Значит вы пришли в симфони изначально из голого «пхп» и чистых sql запросов, когда сам всё создаёшь через пхпмуадмин и понимаешь где и зачем это надо.

[VolCh]

А бывает по другому?

[romy4]

ой как бывает :)

[Chloroform]

Было интересно прочесть. С такими сложностями не сталкивался ещё, но часто приходится заниматься оптимизацией запросов за другими людьми.
Обычно делают так:

select t.*, foo(t.id) 
from table t

Когда лучше делать так:

select t.*, f.* 
from table t 
left join foo() f

Ещё был такой вариант действий в firebird, когда table1 имеет 150 записей, а table2 больше 2 млн.

select *
from table1 t1 
left join table2 t2 on t2.t1_id = t1.id
where t2.date > current_date-1

Замена местами table1 и table2 — помогла сохранить не одну человеческую жизнь.