Comments 25
В наименовании статьи PostgreSQL Antipatterns, а дальше ни слова о PostgreSQL.
Но, скажем так, БД никогда не сможет знать столько же, сколько сам разработчик. Хотя попытки прикрутить machine learning конкретно к планировщику PostgreSQL уже есть.
По-хорошему надо проверять в каждой отдельной субд (и даже на разных версиях одной и той же порой можно словить интересные варианты).
Но вот допустим первый пример это настолько универсальный совет, что мне кажется, что тут можно более-менее смело ручаться что все основные субд будет значительный выигрыш.
Почти уверен, что оракл тоже должен нормально обработать такой случай.
И раз уж мы все равно уже работаем при таких вводных, стоит знать, как именно можно этим управлять.
Это легко описать простой зависимостью — чем проще задачи, в которых планировщику требуется подсказка — тем фиговей он. И наоборот — чем сложнее задачи, начинающие требовать явные подсказки — тем лучше.
Если планировщик плох — код будет выглядеть как нагромаждение нечитаемых костылей, призванных обойти проблемы планировщика…
Не хотел бы критиковать конкретные системы, но первый пример меня огорчил. =(
Насчёт плохого/хорошего планировщика, это часто зависит от того насколько ваши данные и ваши сервера похожи на те, которые подразумевались разработчиками как наиболее частые в использовании пользователями.
Для больших хранилищ данных планировщик иногда мешает, иногда у него просто не может быть достаточно информации для подбора оптимального плана выполнения.
Статистика не?
Применение LEFT JOIN не гарантирует порядка сканирования, а только описывает целевой результат — можно легко получить вообще Merge Join при выполнении.
А CTE — просто не всегда быстро:
https://habr.com/ru/post/479298/
NATURAL JOIN появился в SQL-92, плохо тянет на новомодность. :)
Ещё один конкретный пример того, что оптимизаторы SQL-запросов в СУБД промышленного уровня всё равно тупые. Сколько я намучался в своё время с оптимизатором Oracle, который очень своевольничал, — это не перечесть.
Иными словами: если вы не понимаете структуру ваших данных, то и работа с ними будет далеко неоптимальной.
А как приведенные примеры из статьи уживаются с различными ORM?
PostgreSQL Antipatterns: редкая запись долетит до середины JOIN