PostgreSQL Antipatterns: редкая запись долетит до середины JOIN

[UvaysovRI]

Подскажите, плз, а это только с PostgreSQL такие проблемы или для других БД аналогично?
В наименовании статьи PostgreSQL Antipatterns, а дальше ни слова о PostgreSQL.

[Kilor]

В каждой СУБД планировщик запроса работает по своим принципам. Конкретно для PG приведенные выше примеры и способы справедливы, для других — надо проверять.

Но, скажем так, БД никогда не сможет знать столько же, сколько сам разработчик. Хотя попытки прикрутить machine learning конкретно к планировщику PostgreSQL уже есть.

[dss_kalika]

В MSSQL планы почти идентичны. Между «оптимизированым» и «не очень» из данной статьи.
По моим ощущениям у мелкомягки планировщик немного умнее в этом плане. (с поправкой на особенности принципов работы бд).

[questor]

По-хорошему надо проверять в каждой отдельной субд (и даже на разных версиях одной и той же порой можно словить интересные варианты).

Но вот допустим первый пример это настолько универсальный совет, что мне кажется, что тут можно более-менее смело ручаться что все основные субд будет значительный выигрыш.

[dss_kalika]

Ну, вот, в MSSQL значительного выигрыша нет… потому что планировщик умеет раскладывать подзапросы. =)
Почти уверен, что оракл тоже должен нормально обработать такой случай.

[StrangerInTheKy]

Попробовал на оракле — планы разные, но время выполнения отличается порядка 10% максимум. Но мне кажется, для того железа, что у меня на работе, надо каждую таблицу сделать в 1000 раз больше, чтобы задача представляла хоть какую-то сложность ;)

[Sovetnikov]

Такое чувство, что во втором примере вы просто пытаетесь сделать то что оптимизатор почему-то не сделал… подсказываете ему последовательность filter/join

[Kilor]

Это правильное чувство — любой разработчик только тем и занимается, что «подсказывает» машине делать то, что до него кто-то не сделал. В этом случае — разработчики планировщика PG (не в упрек им), видимо.
И раз уж мы все равно уже работаем при таких вводных, стоит знать, как именно можно этим управлять.

[dss_kalika]

Э-э… нет. Если планировщик достаточно мощный — количество необходимых вмешательств становится очень невелико.
Это легко описать простой зависимостью — чем проще задачи, в которых планировщику требуется подсказка — тем фиговей он. И наоборот — чем сложнее задачи, начинающие требовать явные подсказки — тем лучше.
Если планировщик плох — код будет выглядеть как нагромаждение нечитаемых костылей, призванных обойти проблемы планировщика…

Не хотел бы критиковать конкретные системы, но первый пример меня огорчил. =(

[Kilor]

Надо отдать должное разработчикам PG, что среди всего многообразия встречающихся задач, приходится постараться, чтобы наткнуться на «проблемную» — но так и код планировщика не стоит на месте. Но должен найтись тот, кто это может и хочет доточить — беда OSS.

[nikolayv81]

Насчёт плохого/хорошего планировщика, это часто зависит от того насколько ваши данные и ваши сервера похожи на те, которые подразумевались разработчиками как наиболее частые в использовании пользователями.
Для больших хранилищ данных планировщик иногда мешает, иногда у него просто не может быть достаточно информации для подбора оптимального плана выполнения.

[Sovetnikov]

Неужели в PG нельзя подругому это сделать? Прямо вот нет другого способа подсказать планировщику в этом случае последовательность фильтрации?
Статистика не?

[Kilor]

Если условия во втором примере представлены не статичными полями в ext1/ext2, а динамическими выражениями (от пользовательских фильтров), то статистика особо и не поможет.

[Kilor]

Применение LEFT JOIN не гарантирует порядка сканирования, а только описывает целевой результат — можно легко получить вообще Merge Join при выполнении.
А CTE — просто не всегда быстро:
https://habr.com/ru/post/479298/

NATURAL JOIN появился в SQL-92, плохо тянет на новомодность. :)

[Kilor]

Не совсем понял, что имеется в виду. Накладываемые условия ведь зависят не от нас.
Можно пример запроса?

[Kilor]

Теорию-то я понял — я не понял, как именно на практике под эту модель переписать запрос для 2й задачи.

[sadko4u]

Ещё один конкретный пример того, что оптимизаторы SQL-запросов в СУБД промышленного уровня всё равно тупые. Сколько я намучался в своё время с оптимизатором Oracle, который очень своевольничал, — это не перечесть.
Иными словами: если вы не понимаете структуру ваших данных, то и работа с ними будет далеко неоптимальной.

[Naves]

Поздновато, но вдруг.
А как приведенные примеры из статьи уживаются с различными ORM?

[Kilor]

В смысле «как получить такой запрос с помощью ORM»?

[Naves]

Да.

[Kilor]

Нет, не в курсе, стараюсь не пользоваться ORM — от их кажущейся простоты обычно для производительности больше вреда, чем пользы.