Comments 16
Немного личных исследований производительности запросов http://egaxegax.appspot.com/posts/77004.
И еще насчет join'ов. Вместо стандартного вида
можно написать так
В этом случае выполнив отдельные подзапросы можно узнать сколько времени онb выполняются и так проанализировать все join'ы поштучно.
И еще насчет 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'ы поштучно.
+3
Кроме того, подозрительны запросы с большим OFFSET, обычные пользователи такие не делают, а стоимость их высока.
+1
Наверное я необычный пользователь, но если мне сказать что в данных 100500 страниц, мне обязательно будет интересно что там на последней и что там на 50200 :)…
+1
Кстати, произвольный offset без потери производительности возможен в PG.
https://www.depesz.com/2011/05/20/pagination-with-fixed-order/
Конечно, при помощи сложных ухищрений и со множеством ограничений. Но, если какой-то сервис крутится только вокруг pagination, это можно сделать.
https://www.depesz.com/2011/05/20/pagination-with-fixed-order/
Конечно, при помощи сложных ухищрений и со множеством ограничений. Но, если какой-то сервис крутится только вокруг pagination, это можно сделать.
0
По опыту, если сложный запрос написан без очевидных ошибок, но план выполнения подозрительный, то первым делом смотрю разницу между estimated rows и actual rows. Часто дело именно в неверном предположении о количестве возвращаемых рядов, которое потом может кратно умножаться по мере продвижения по дереву.
+1
> Поэтому все программисты любят индексы
кроме symfony-стов :)
кроме symfony-стов :)
0
Было интересно прочесть. С такими сложностями не сталкивался ещё, но часто приходится заниматься оптимизацией запросов за другими людьми.
Обычно делают так:
Когда лучше делать так:
Ещё был такой вариант действий в firebird, когда table1 имеет 150 записей, а table2 больше 2 млн.
Замена местами table1 и table2 — помогла сохранить не одну человеческую жизнь.
Обычно делают так:
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 — помогла сохранить не одну человеческую жизнь.
0
Sign up to leave a comment.
Производительность запросов в PostgreSQL – шаг за шагом