HAVING против WHERE: фильтр до или после группировки

Два фильтра в два разных момента

У агрегации фиксированный конвейер, и два фильтрующих предложения стоят по разные стороны свёртки:

1. FROM / JOIN — собрать сырые строки.
2. WHERE — отбросить строки, которые не нужны. Работает до группировки, поэтому действует на отдельные строки и не видит ни одного агрегата (групп ещё нет).
3. GROUP BY — свернуть пережившие строки в корзины.
4. HAVING — отбросить целые группы, которые не нужны. Работает после агрегации, поэтому может ссылаться на агрегаты вроде SUM(total) или COUNT(*).
5. SELECT / ORDER BY / LIMIT — оформить вывод.

В совокупности эти шаги означают, что у каждого фильтра есть ровно одно верное место: если условие об отдельной строке — шаг 2 (WHERE); если о результате свёртки группы — шаг 4 (HAVING). Поставишь построчный фильтр на шаг 4 — зря оплатишь всю работу группировки по строкам, которые собирался выбросить.

Конкретно — правильный отчёт:

SELECT user_id, SUM(total) AS paid_revenue
FROM orders
WHERE status = 'paid'          -- построчное условие → до группировки
GROUP BY user_id
HAVING SUM(total) > 10000;      -- условие на агрегат → после группировки

status = 'paid' решается на одной строке, поэтому идёт в WHERE и сжимает вход для GROUP BY. SUM(total) > 10000 можно вычислить только когда целая корзина существует, поэтому это обязательно HAVING.

Почему агрегаты в WHERE недопустимы

Попробуй перенести порог в WHERE — и Postgres откажет:

SELECT user_id, SUM(total)
FROM orders
WHERE SUM(total) > 10000        -- ERROR: aggregate functions are not allowed in WHERE
GROUP BY user_id;

Это не недостающая фича — это невозможность по времени. WHERE работает до GROUP BY, в точке, где ещё нет ни одной группы, так что SUM(total) нечего суммировать. Агрегат в этот момент не определён. HAVING существует именно как фильтр, работающий после того, как группы (и их агрегаты) материализуются.

Рычаг производительности: проталкивай фильтры вниз

Вот часть, отделяющая корректный запрос от быстрого. Оба возвращают одни и те же строки:

-- МЕДЛЕННО: каждый заказ группируется, потом неоплаченные группы... всё равно неверно и дорого
SELECT user_id, SUM(total)
FROM orders
GROUP BY user_id
HAVING bool_and(status = 'paid');   -- вычурно и сначала группирует ВСЕ заказы

-- БЫСТРО: отбросить неоплаченные строки до того, как они дойдут до группировки
SELECT user_id, SUM(total)
FROM orders
WHERE status = 'paid'
GROUP BY user_id;

Построчный фильтр место в WHERE, чтобы до (дорогого) шага группировки доходило меньше строк. Группировке приходится хешировать или сортировать вход; вдвое меньший вход примерно вдвое дешевле, а если есть частичный индекс по status, планировщик может вовсе пропустить несовпадающие строки. Положить простое построчное условие в HAVING — это code smell (признак проблемного кода): обычно это значит, что фильтр, который должен был отработать до группировки, работает после неё, выполняя всю работу группировки над строками, которые ты собирался выбросить.

Подкрепим цифрами. На таблице orders в 12М строк, где paid всего ~1.2М, версия только с HAVING в EXPLAIN ANALYZE выглядит как Seq Scan (rows=12000000), питающий HashAggregate, который строит корзину для каждого пользователя — 9с по часам, причём агрегат спиллит на диск (Disk Usage: 180000 kB), ведь пришлось материализовать все 2М групп пользователей. Перенеси status='paid' в WHERE — и план становится Bitmap Index Scan по частичному индексу WHERE status='paid', возвращающим rows=1200000, который питает HashAggregate из ~400k корзин переживших пользователей, теперь влезающий в work_mem (строки Disk нет) — ~200мс. Те же строки результата, но группировка пережевала в 10 раз меньше входных строк и построила в ~5 раз меньше корзин. Этот рычаг не микрооптимизация: это разница между запросом на 9с и на 0.2с.