Комментарии 19
Доброго времени суток. Подскажите а у вас в приложении действительно такие сложные сценарии/запросы используются? В первый раз вижу такие сложные оптимизации запросов (если в целом брать ваши статьи).
Да, это реальные кейсы. Иногда разница в нагрузке между наивной и оптимизированной версией бывает кратной, а «железо» все-таки не резиновое.
это все довольно простые запросы. Сложные — это запросы с полусотней джоинов, и подзапросами в 3-4 уровня. Причем на многомилионных таблицах.
Что-то типа такого? :)
Многие со мной не согласятся, но я считаю, что «полусотня джойнов» — это все-таки антипаттерн, если нет задачи «написать, чтобы просто хоть один раз отработал».
Ну и проблемы в больших и сложных запросах обычно появляются как следствие проблем в их маленьких кусочках — вроде таких вариантов с DISTINCT.
Многие со мной не согласятся, но я считаю, что «полусотня джойнов» — это все-таки антипаттерн, если нет задачи «написать, чтобы просто хоть один раз отработал».
Ну и проблемы в больших и сложных запросах обычно появляются как следствие проблем в их маленьких кусочках — вроде таких вариантов с DISTINCT.
Ну для витрин данных — просто разбивать 50 джоинов на 5 подвитрин по 10 — смысла не много, если они не переиспользуются. А полста джоинов — это еще мало если просто справочников на факте висит пару дюжин (а бывает для нормального отчета надо и 100 справочников). Конечно большинство из них прямые и простые как валенок хэш джоины, без сюрпризов, но обязательно попадется и справочник без pk, и scd2 и фактов не один а штук 10. И вот уже джоины с подзапросами и дедубликакцией и оконных функций полно т.д. в итоге и получается 5 страниц кода в одном запросе.
Хотя работает при этом все один проход и быстро.
Хотя работает при этом все один проход и быстро.
А разве планировщик/оптимизатор не соптимизирует такие запросы, даже если написать откровенную чушь?
SELECT
*
FROM
X
WHERE
EXISTS(
SELECT
NULL
FROMNULL тут лишний.
А как же без него?
Так:
SELECT
*
FROM
X
WHERE
EXISTS(
SELECT
FROMselect без полей — это как-то совсем некрасиво. А парсер от какой версии такое понимает?
Можете объяснить, почему во втором примере («Зачем платить больше»: DISTINCT [ON] + LIMIT 1) запросы эквивалентны в общем случае?
Если рассматривать join, а не left join, то возможна же ситуация, когда этот
джоин даст в результате 0 записей. Хотя если убрать LIMIT 1, то записи найдутся.
Если рассматривать join, а не left join, то возможна же ситуация, когда этот
SELECT
*
FROM
(
SELECT
*
FROM
X
-- сюда можно подсунуть подходящих условий
LIMIT 1 -- +1 Limit
) X
JOIN
Y
ON Y.fk = X.pkджоин даст в результате 0 записей. Хотя если убрать LIMIT 1, то записи найдутся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostgreSQL Antipatterns: «Должен остаться только один!»