WITH days AS (
SELECT DISTINCT
user_id,
DATE(created_at) AS d
FROM orders
),
grp AS (
SELECT
user_id,
d,
-- трюк: для подряд идущих дат разность (дата - номер) постоянна
DATEADD(day, -ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY d), d) AS g
FROM days
),
streaks AS (
SELECT
user_id,
MIN(d) AS streak_start,
MAX(d) AS streak_end,
COUNT(*) AS streak_len
FROM grp
GROUP BY user_id, g
)
SELECT user_id, streak_start, streak_end, streak_len
FROM streaks
WHERE streak_len >= 3
ORDER BY streak_len DESC;

 ПЛОХО: тащим весь объём и только потом думаем
SELECT *
FROM events
WHERE created_at >= NOW() - INTERVAL '90 days';

-- ХОРОШО: сразу сужаем, берем нужные колонки, считаем агрегаты
SELECT
  user_id,
  COUNT(*) AS events_7d,
  MAX(created_at) AS last_event_at
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

-- Индекс под фильтр по времени + join по user_id (частый паттерн)
CREATE INDEX IF NOT EXISTS idx_events_created_user
ON events (created_at, user_id);

-- Проверяй план, чтобы не было Seq Scan на миллионах строк
EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id, COUNT(*)
FROM events
WHERE created_at >= NOW() - INTERVAL '7 days'
GROUP BY user_id;

📎Решение застарелых архитектурных проблем PostgreSQL для современных нагрузок и масштабирования
📎Временные таблицы для Postgres. Почему это важно для платформы 1С и что можно улучшить?
📎Разделение Compute и Storage: архитектурный прорыв для PostgreSQL в облаке
📎Опыт вынесения OLAP-нагрузки на реплику
📎Highload "из ниоткуда": когда проблема не в СУБД, а в клиентской архитектуре
📎Опыт эксплуатации, проблемы и производительность PostgreSQL на Эльбрус, Baikal-S, Loongson, Repka Pi, x86
📎Поиск проблем планирования запросов до их воздействия на производительность
📎Тестирование, баги и уроки работы с патчем 64-битного счетчика транзакций PostgreSQL
📎Работа с логами PostgreSQL
📎…и другие (всего 25 выступлений)