Фреймы окна: ROWS против RANGE против GROUPS

Фрейм — это срез, который реально агрегируется

PARTITION BY решает, какие строки делят окно; ORDER BY упорядочивает их; фрейм решает, какое подмножество этой упорядоченной партиции функция агрегирует для каждой строки. Фрейм — это подвижное окно-внутри-окна. Для накопительного итога на строке 5 фрейм — «строки с 1 по 5»; на строке 6 он скользит до «строк с 1 по 6». У синтаксиса фрейма три части: режим (ROWS / RANGE / GROUPS) и две границы.

Границы, которыми будешь пользоваться постоянно:

• UNBOUNDED PRECEDING — первая строка партиции.
• CURRENT ROW — где сейчас идёт вычисление.
• n PRECEDING / n FOLLOWING — n позиций назад или вперёд.
• UNBOUNDED FOLLOWING — последняя строка партиции.

Так что ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW — классический накопительный итог; ROWS BETWEEN 2 PRECEDING AND CURRENT ROW — трёхстрочное окно назад (скользящее среднее); ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING — вся партиция. Вместе режим и границы дают точный контроль над тем, какие строки питают вычисление — без их явного указания ты наследуешь дефолт, который может быть не тем, что ты хочешь.

RANGE против ROWS: разница в ничьих

ROWS считает физические строки: 1 PRECEDING значит буквально одну строку перед этой. RANGE работает на значениях выражения ORDER BY: CURRENT ROW в режиме RANGE не значит «эту одну строку» — он значит «все строки, чьё значение ORDER BY равно значению этой строки», то есть всех пиров. Если три продажи делят sale_date = '2026-01-10', эти три строки — пиры, и под RANGE они входят и выходят из фрейма вместе.

Для накопительного SUM, упорядоченного по sale_date, последствие точное и вредное: на связанной дате каждая из связанных строк получает одинаковый накопительный итог — итог включая всех пиров — вместо накопления по одной. Первая связанная строка уже показывает полный вклад дня; остальные его повторяют. Если твой отчёт ждёт, что каждая строка добавит свою сумму по порядку, связанные строки неверны.

-- Фрейм по умолчанию == RANGE; строки с тем же sale_date делят один накопительный итог (переполняют ранние строки)
SELECT sale_date, amount,
       SUM(amount) OVER (ORDER BY sale_date) AS running_default
FROM sales;

-- Фрейм ROWS: каждая физическая строка добавляет ровно свою сумму, по порядку
SELECT sale_date, amount,
       SUM(amount) OVER (ORDER BY sale_date
                         ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS running_rows
FROM sales;

Фрейм по умолчанию и продакшен-правило

Когда ты добавляешь ORDER BY внутрь OVER и не задаёшь фрейм, Postgres использует RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW. Это дефолт стандарта SQL — и это RANGE, а не ROWS. На данных без ничьих в колонке ORDER BY оба идентичны, и именно поэтому баги проскальзывают: работает на чистом dev-наборе и ломается в день, когда в продакшене две строки с одинаковым timestamp или датой.

Продакшен-правило прямое: для любого накопительного агрегата пиши ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW явно. Это делает фрейм физическим (по одной строке за раз), это обычно ещё и быстрее (Postgres не нужно сканировать вперёд в поисках всех пиров) и убирает тихое поведение на ничьих. Используй RANGE только когда тебе действительно нужны сгруппированные пиры — например, фрейм на основе значения вроде RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW, который ROWS выразить не может. GROUPS — третий режим: его границы считают группы пиров, а не строки или значения — GROUPS 1 PRECEDING тянется назад на одну целую группу-ничью — редкий, но точный инструмент, когда нужны «строки предыдущей отдельной даты, сколько бы их ни было».