Bagaimana cara kerja materialized view di PostgreSQL?

Question

Accepted Answer

Sebuah **materialized view** menyimpan *hasil* dari sebuah query secara fisik (precomputed), tidak seperti regular view (yang menjalankan kembali querynya setiap kali). Ini membuat pembacaan cepat untuk query yang mahal, dengan biaya data hanya segar sesuai **refresh** terakhir — sebuah mekanisme caching dalam database.

## Regular view vs materialized view

```sql
-- regular VIEW — runs the query EVERY time (always fresh, but recomputed)
CREATE VIEW sales_summary AS SELECT region, SUM(amount) FROM orders GROUP BY region;

-- MATERIALIZED VIEW — stores the RESULTS physically (fast reads, but can be stale)
CREATE MATERIALIZED VIEW sales_summary_mat AS
SELECT region, SUM(amount) AS total FROM orders GROUP BY region;

SELECT * FROM sales_summary_mat;     -- reads STORED results — fast (no recompute)
```

Sebuah materialized view melakukan precompute dan menyimpan hasil, sehingga query-nya cepat (seperti membaca table) — ideal untuk aggregasi mahal yang sering di-query.

## Refreshing (memperbarui data yang disimpan)

```sql
-- the data is stale until you refresh it
REFRESH MATERIALIZED VIEW sales_summary_mat;          -- recompute (locks reads during refresh)

-- CONCURRENTLY — refresh WITHOUT blocking reads (requires a unique index)
CREATE UNIQUE INDEX idx_sales_region ON sales_summary_mat(region);
REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary_mat;   -- reads continue during refresh
```

Anda harus **refresh** untuk memperbarui data. `REFRESH ... CONCURRENTLY` (memerlukan unique index) memperbarui tanpa memblokir concurrent reads — penting untuk production.

## Kapan menggunakan materialized views

```text
✓ EXPENSIVE queries (complex aggregations, joins) queried FREQUENTLY
✓ Data that doesn't need real-time freshness (dashboards, reports, analytics)
✓ Reducing load from repeatedly running the same heavy query
→ Refresh on a schedule (cron / pg_cron) or after data changes.

✗ Data needing real-time accuracy → use a regular view or query directly
```

## Trade-off

```text
Fast reads (precomputed) ⟷ Stale data (until refreshed) + storage cost.
You trade freshness and storage for read speed — a caching decision.
You can also index a materialized view (it's a physical table of results).
```

## Mengapa ini penting

Materialized view adalah fitur PostgreSQL yang berharga untuk **optimisasi performa** — mereka menyediakan mekanisme caching dalam database untuk query yang mahal, jadi memahami mereka berguna untuk mengoptimalkan aplikasi dengan query yang costly dan sering dijalankan.

Nilai inti adalah melakukan precompute dan menyimpan hasil dari query yang mahal (aggregasi kompleks, join berat) sehingga membacanya cepat (seperti query table) daripada menjalankan kembali query yang costly setiap kali — yang merupakan optimisasi signifikan untuk dashboard, laporan, dan analytics dimana query berat yang sama berjalan berulang kali.

Memahami **trade-off** utama penting: materialized view memberikan pembacaan cepat tapi data **stale** sampai di-refresh (dan mereka menggunakan storage), jadi mereka adalah keputusan caching yang cocok untuk data yang tidak memerlukan freshness real-time.

Mengetahui cara **refresh** mereka — khususnya `REFRESH ... CONCURRENTLY` (yang memperbarui tanpa memblokir read, penting untuk availability production, memerlukan unique index) — dan strategi refresh (pada schedule via cron/pg_cron, atau setelah data berubah) adalah pengetahuan praktis untuk menggunakan mereka secara efektif.

Memahami **kapan menggunakan** materialized view (query yang expensive dan sering dijalankan yang toleran dengan slight staleness — dashboard, analytics) versus kapan tidak menggunakan (data yang memerlukan akurasi real-time) mencerminkan judgment yang sound.

Karena query berulang yang expensive adalah concern performa real, dan karena materialized view menyediakan solusi caching dalam database yang efektif (precomputed, indexable results) dengan trade-off freshness/speed yang jelas, memahami mereka — cara kerjanya, refreshing (khususnya concurrently), trade-off, dan penggunaan yang sesuai — adalah pengetahuan PostgreSQL yang berharga dan praktis-relevan untuk mengoptimalkan performa analytical dan reporting query, sebuah kebutuhan umum dimana materialized view menawarkan solusi built-in yang clean.