Ускоряй отчёты с материализованными представлениями!

Когда отчёты считаются минутами, а данные почти не меняются, решение может быть в кэшировании результата.

Используй материализованное представление (как VIEW, но результат хранится физически в таблице):

CREATE MATERIALIZED VIEW daily_stats AS
SELECT date(created_at) AS day,
       COUNT(*) AS total_orders
FROM orders
GROUP BY 1;

CREATE UNIQUE INDEX ON daily_stats(day);  -- нужно для CONCURRENTLY

Обновлять можно вручную или по расписанию (cron, pg_cron):

REFRESH MATERIALIZED VIEW_stats;

А если нужно без блокировок чтения:

REFRESH MATERIALIZED VIEW CONCURRENTLY daily_stats;

🔥 Помни: concurrently медленнее и требует индекс, но позволяет читать данные во время обновления.

➡️ SQL Ready | #совет

Выбираем уникальные записи с приоритетом по дате!

Когда нужно взять по одной записи на пользователя, DISTINCT не всегда подходит: он не умеет выбирать, какая строка «главная». В PostgreSQL есть мощный приём — DISTINCT ON.

Создадим таблицу:

CREATE TABLE users (
    id INT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    email TEXT NOT NULL,
    login_count INT,
    created_at TIMESTAMP DEFAULT now()
);

Добавим данные:

INSERT INTO users (email, login_count, created_at) VALUES
('alice@mail.com', 5, '2024-01-01'),
('alice@mail.com', 8, '2024-03-01'),
('bob@mail.com',   2, '2024-02-01');

Теперь выберем только последнюю запись на каждый email:

SELECT DISTINCT ON (email)
       email, login_count, created_at
FROM users
ORDER BY email, created_at DESC, id DESC;

Результат:

email           | login_count | created_at
----------------+--------------+----------
alice@mail.com  | 8            | 2024-03-01
bob@mail.com    | 2            | 2024-02-01

🔥 DISTINCT ON берёт по одной строке на группу, а ORDER BY задаёт, какая именно — последняя, первая или с нужным приоритетом.

➡️ SQL Ready | #практика