Database

Декларативное партиционирование в PostgreSQL требует, чтобы кто-то заранее создавал секции под будущие даты — вручную или крон-скриптом, иначе вставка в несуществующий диапазон просто упадёт с ошибкой. TimescaleDB — это расширение поверх PostgreSQL, которое берёт ровно эту рутину на себя: таблица превращается в hypertable, а партиции («чанки») создаются автоматически по мере поступления данных. CREATE TABLE metrics ( time TIMESTAMPTZ NOT NULL, host TEXT NOT NULL, cpu_percent DOUBLE PRECISION ); SELECT create_hypertable('metrics', 'time'); Снаружи metrics выглядит как обычная таблица — тот же INSERT, тот же SELECT — но физически строки лежат по чанкам фиксированного временного интервала (по умолчанию 7 дней, меняется через chunk_time_interval в create_hypertable или глобально через timescaledb.default_chunk_time_interval). Новый чанк создаётся сам, как только приходит строка с временем за пределами существующих — никакого аналога CREATE TABLE ... PARTITION OF под будущий месяц заранее. ...

pg_stat_activity — представление с одной строкой на каждое соединение к базе: кто подключён, что выполняет прямо сейчас и сколько это уже длится. SELECT pid, state, now() - query_start AS duration, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC; Колонка state — главное, на что смотреть: active — запрос реально выполняется; idle — соединение открыто, но ничего не делает; idle in transaction — самое опасное значение, транзакция открыта и висит, держит блокировки и мешает autovacuum чистить мёртвые строки. ...

EXPLAIN показывает план планировщика (Seq Scan, Index Scan, Nested Loop, Hash Join) без выполнения запроса. EXPLAIN ANALYZE запускает его по-настоящему, добавляя время и число строк на узел. EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 42; ⚠️ На INSERT/UPDATE/DELETE EXPLAIN ANALYZE реально пишет в таблицу — оборачивай в BEGIN; ... ROLLBACK;. Буферы (кэш vs диск) — первое, что смотрят при разборе медленного запроса: EXPLAIN (ANALYZE, BUFFERS) .... Главное в плане: cost=startup..total — оценка планировщика, не секунды; rows vs actual rows — расхождение значит устаревшую статистику (ANALYZE table_name); Seq Scan вместо Index Scan — повод проверить индекс. ...

pg_stat_statements — расширение, которое собирает статистику по каждому нормализованному запросу на сервере: сколько раз вызван, суммарное и среднее время выполнения, сколько строк вернул. Без него узкие места ищутся вслепую по логам. Включить: добавить в postgresql.conf и перезапустить кластер, затем создать расширение: shared_preload_libraries = 'pg_stat_statements' CREATE EXTENSION pg_stat_statements; Топ-10 самых тяжёлых запросов по суммарному времени: SELECT query, calls, total_exec_time, mean_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10; Сбросить накопленную статистику: SELECT pg_stat_statements_reset();. Для учёта времени на дисковый I/O отдельно от CPU включи track_io_timing = on. ...

Autovacuum срабатывает, когда количество мёртвых кортежей превышает порог: threshold + scale_factor × n_live_tup По умолчанию: 50 + 0.2 × размер_таблицы. Для большой таблицы это слишком много — bloat накапливается быстро. Настроить на уровне таблицы: ALTER TABLE orders SET ( autovacuum_vacuum_scale_factor = 0.01, autovacuum_vacuum_threshold = 100 ); Смотреть когда последний раз убиралось и сколько мёртвых кортежей сейчас: SELECT relname, n_dead_tup, last_autovacuum, last_autoanalyze FROM pg_stat_user_tables ORDER BY n_dead_tup DESC; autovacuum_naptime (по умолчанию 1 мин) — как часто демон проверяет таблицы. На нагруженных базах снизить до 15s. ...

statement_timeout прерывает запрос, если он работает дольше лимита. Postgres бросает ERROR: canceling statement due to statement timeout. На практике ставят на уровне роли приложения — не глобально: ALTER ROLE app SET statement_timeout = '3s'; -- или на сессию при открытии соединения: SET statement_timeout = '10s'; Глобально в postgresql.conf — риск: попадут VACUUM, REINDEX, ALTER TABLE, pg_dump и запросы обслуживания. Autovacuum и autoanalyze — фоновые воркеры вне сессии, не затронуты. statement_timeout отсчитывает время с начала выполнения, включая ожидание блокировки. Для долгого lock-wait — lock_timeout. Для брошенных транзакций — idle_in_transaction_session_timeout. ...