Как работает разбиение таблиц в PostgreSQL?

Question

Accepted Answer

**Разбиение** (partitioning) разделяет большую таблицу на меньшие физические части (**партиции**) на основе значения столбца, при этом она остаётся одной логической таблицей. **Декларативное разбиение** PostgreSQL (Postgres 10+) делает это чистым и удобным. Это улучшает производительность и управляемость для очень больших таблиц.

## Декларативное разбиение (современный подход)

```sql
-- create a partitioned table, partitioned by RANGE on a date
CREATE TABLE orders (id INT, order_date DATE, amount NUMERIC)
PARTITION BY RANGE (order_date);

-- create partitions for each range
CREATE TABLE orders_2023 PARTITION OF orders
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
CREATE TABLE orders_2024 PARTITION OF orders
  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
```

`orders` — это одна логическая таблица, физически хранящаяся в партициях по годам. Вставки и запросы автоматически направляются в нужную партицию.

## Pruning партиций — ключевое преимущество производительности

```sql
-- a query filtered on the partition key scans ONLY relevant partitions
SELECT * FROM orders WHERE order_date >= '2024-06-01';
-- → Postgres skips orders_2023 entirely ("partition pruning") — scans only orders_2024
```

**Pruning партиций** — основное преимущество: запросы с фильтром по ключу разбиения касаются только релевантных партиций, что резко снижает объём сканируемых данных на огромных таблицах.

## Стратегии разбиения

```text
PARTITION BY RANGE → value ranges (dates, numbers) — common for time-series
PARTITION BY LIST  → discrete values (region, status)
PARTITION BY HASH  → hash of the key (even distribution across N partitions)
```

## Преимущества обслуживания

```sql
-- drop old data instantly by dropping a whole partition (vs slow DELETE)
DROP TABLE orders_2020;              -- removes all 2020 data instantly
-- vs DELETE FROM orders WHERE year = 2020 → slow, creates bloat

-- detach/attach partitions; automate with pg_partman extension
```

Удаление целой партиции для архивирования или удаления старых данных выполняется мгновенно — значительное операционное преимущество по сравнению с `DELETE` для больших наборов данных.

## Почему это важно

Разбиение таблиц — важный метод PostgreSQL для управления и запросов **очень больших таблиц**, и понимание этого ценно при работе с Postgres в масштабе.

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

**Декларативное разбиение** PostgreSQL (Postgres 10+) делает это чистым и современным стандартом, который нужно знать.

Ключевое преимущество производительности — **pruning партиций**: запросы с фильтром по ключу разбиения сканируют только релевантные партиции (пропуская остальные), что резко снижает объём сканируемых данных на огромных таблицах (особенно ценно для временных рядов, отфильтрованных по дате — очень частый случай).

Помимо производительности, разбиение даёт значительные **преимущества в обслуживании**: архивирование или удаление старых данных становится мгновенным благодаря удалению целой партиции (в отличие от медленного, вызывающего фрагментацию `DELETE` миллионов строк — значительное операционное преимущество для данных с политиками хранения, таких как логи и события).

Понимание **стратегий** (RANGE для диапазонов дат/чисел — распространено для временных рядов; LIST для дискретных значений; HASH для равномерного распределения) и **когда использовать разбиение** (очень большие таблицы с естественным ключом разбиения, особенно временные ряды с регулярным архивированием — не маленькие таблицы, где индексирования достаточно) отражает здравое суждение.

Поскольку управление очень большими таблицами — реальный вызов в масштабируемых системах PostgreSQL, и поскольку декларативное разбиение (с pruning партиций и эффективным удалением партиций) — стандартный инструмент, дополняющий индексирование — понимание разбиения таблиц PostgreSQL представляет собой ценное, практически релевантное знание для масштабируемости баз данных, особенно важное для крупномасштабных приложений с высоким объёмом данных или приложений временных рядов и часто встречающаяся тема, демонстрирующая способность управлять Postgres в масштабе.