Bagaimana cara kerja partisioning tabel di PostgreSQL?

Question

Accepted Answer

**Partisioning** membagi sebuah tabel besar menjadi potongan fisik yang lebih kecil (**partisi**) berdasarkan nilai kolom, namun tetap menjadi satu tabel logis. **Declarative partitioning** PostgreSQL (Postgres 10+) membuat hal ini menjadi bersih. Ini meningkatkan performa dan kelola-ablitas untuk tabel yang sangat besar.

## Declarative partitioning (cara modern)

```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` adalah satu tabel logis, secara fisik disimpan dalam partisi per-tahun. Insert dan query secara otomatis di-route ke partisi yang benar.

## Partition pruning — manfaat performa kunci

```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
```

**Partition pruning** adalah keuntungan utama: query yang memfilter pada partition key hanya menyentuh partisi yang relevan, secara dramatis mengurangi data yang dipindai pada tabel besar.

## Strategi partisioning

```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)
```

## Manfaat maintenance

```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
```

Menghapus seluruh partisi untuk mengarsipkan/menghapus data lama sangat cepat — keuntungan operasional besar dibandingkan `DELETE` untuk dataset besar.

## Mengapa ini penting

Partisioning tabel adalah teknik PostgreSQL penting untuk mengelola dan query **tabel yang sangat besar**, dan memahaminya sangat berharga untuk bekerja dengan Postgres pada skala besar.

Saat tabel tumbuh menjadi ratusan juta atau miliaran baris, partisioning mengatasi performa dan kelola-ablitas dengan membagi tabel menjadi potongan fisik yang lebih kecil.

**Declarative partitioning** PostgreSQL (Postgres 10+) membuat hal ini bersih dan merupakan standar modern yang penting diketahui.

Manfaat performa kunci adalah **partition pruning** — query yang memfilter pada partition key hanya memindai partisi yang relevan (melewatkan sisanya), secara dramatis mengurangi data yang dipindai untuk tabel besar (sangat berharga untuk data time-series yang difilter berdasarkan tanggal, kasus yang sangat umum).

Selain performa, partisioning memberikan **manfaat maintenance** besar: mengarsipkan atau menghapus data lama menjadi cepat dengan menghapus seluruh partisi (versus `DELETE` lambat yang menciptakan bloat dari jutaan baris — keuntungan operasional signifikan untuk data dengan kebijakan retensi, seperti log dan event).

Memahami **strategi** (RANGE untuk range tanggal/numerik — umum untuk time-series; LIST untuk nilai diskrit; HASH untuk distribusi merata) dan **kapan menggunakan partisioning** (tabel sangat besar dengan partition key alami, khususnya time-series dengan pengarsipan reguler — bukan tabel kecil di mana indexing cukup) mencerminkan pertimbangan yang tepat.

Karena mengelola tabel sangat besar adalah tantangan nyata dalam sistem PostgreSQL berskala besar, dan karena declarative partitioning (dengan partition pruning dan maintenance partition-drop yang efisien) adalah alat standar — melengkapi indexing — memahami partisioning tabel PostgreSQL adalah pengetahuan berharga dan praktis-relevan untuk skalabilitas database, khususnya penting untuk aplikasi berskala besar, high-volume, atau time-series dan topik umum yang menunjukkan kemampuan mengelola Postgres pada skala besar.