Оконные функции против GROUP BY

GROUP BY схлопывает, окно хранит каждую строку

GROUP BY — это редьюсер. Ты даёшь ему много строк, он возвращает по одной строке на группу. После GROUP BY region у тебя четыре строки — по одной на регион — и увидеть отдельные продажи уже нельзя, потому что они свёрнуты в агрегат. В этом весь смысл группировки: схлопнуть детали в сводку.

Оконная функция выполняет ту же агрегатную математику, но выдаёт результат рядом с каждой исходной строкой. Ничего не схлопывается. Именно клауза OVER (...) делает функцию оконной: она говорит Postgres «вычисли это по набору связанных строк — окну — но прикрепи ответ к каждой строке, а не сворачивай строки вместе».

-- GROUP BY: 4 строки на выходе, детали потеряны
SELECT region, SUM(amount) AS region_total
FROM sales
GROUP BY region;

-- Окно: каждая строка продажи сохранена, итог региона прикреплён к каждой
SELECT region, salesperson, sale_date, amount,
       SUM(amount) OVER (PARTITION BY region) AS region_total
FROM sales;

Первый запрос отвечает «сколько продал каждый регион?» Второй — «покажи каждую продажу и итог её региона в одной строке» — а это ровно то, что нужно тикету дашборда. Тот же SUM, та же логика группировки по region; единственное структурное отличие — OVER (PARTITION BY region) вместо GROUP BY region.

Паттерн «процент от итога» в одном запросе

Поскольку окно хранит каждую строку, ты можешь смешать детальное значение и агрегат в одном SELECT и поделить их — без self-join, без подзапроса:

SELECT region, salesperson, amount,
       ROUND(
         100.0 * amount / SUM(amount) OVER (PARTITION BY region),
         1
       ) AS pct_of_region
FROM sales
ORDER BY region, pct_of_region DESC;

amount — собственное значение строки; SUM(amount) OVER (PARTITION BY region) — итог её региона, посчитанный по всем строкам того же региона. Делишь и получаешь долю каждой продажи в её регионе — на строку. С обычным GROUP BY для этого пришлось бы считать итоги отдельно и присоединять их обратно — больше кода и второй проход по данным.

Когда что брать — правило выбора

Спроси себя: звучит ли в требовании «на каждую строку» или «на строку» рядом с агрегатом? Именно этот вопрос определяет инструмент.

Выбор не про то, что «лучше»; он про форму ответа, который тебе нужен:

• Нужна только сводка (по одной строке на группу)? Бери GROUP BY. Отчёты, счётчики по статусам, дневные итоги.
• Нужны детальные строки и агрегат в одной строке? Бери окно. Процент от итога, ранг внутри группы, текущий баланс, «как эта строка соотносится со средним по своей группе».

Надёжное продакшен-правило: если в требовании рядом с агрегатом стоит слово «каждый» или «на строку» — тебе нужно окно. «Покажи каждый заказ с пожизненным итогом его клиента» — окно. «Покажи итог на клиента» — GROUP BY. Перепутать их — классический баг джуна: тянуться к GROUP BY, а потом обнаружить, что нужные детальные строки исчезли, или пытаться положить неагрегированную колонку в GROUP BY-запрос и упереться в column must appear in the GROUP BY clause.