PostgreSQL ਵਿੱਚ materialized views ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ?

Question

Accepted Answer

ਇੱਕ **materialized view** ਇੱਕ ਕਿਊਰੀ ਦੇ *ਨਤੀਜਿਆਂ* ਨੂੰ ਭੌਤਿਕ ਤੌਰ ਤੇ (ਪੂਰਵ-ਗਣਨਾ ਕੀਤਾ) ਸਟੋਰ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਇੱਕ ਨਿਯਮਤ view (ਜੋ ਹਰ ਵਾਰ ਆਪਣੀ ਕਿਊਰੀ ਨੂੰ ਮੁੜ-ਚਲਾਉਂਦਾ ਹੈ) ਨਹੀਂ। ਇਹ ਮਹਿੰਗੀ ਕਿਊਰੀਜ਼ ਲਈ ਪੜ੍ਹਨਨ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਡੇਟਾ ਸਿਰਫ ਆਖ਼ਰੀ **refresh** ਜਿੰਨਾ ਤਾਜ਼ਾ ਹੁੰਦਾ ਹੈ — ਡਾਟਾਬੇਸ ਦੇ ਅੰਦਰ ਇੱਕ ਕੈਸ਼ਿੰਗ ਮਕੇਨਿਜ਼ਮ।

## Regular view ਬਨਾਮ 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)
```

ਇੱਕ materialized view ਨਤੀਜਿਆਂ ਨੂੰ ਪੂਰਵ-ਗਣਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਸਟੋਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਕਿਊਰੀ ਕਰਨਾ ਤੇਜ਼ ਹੈ (ਇੱਕ ਟੇਬਲ ਨੂੰ ਪੜ੍ਹਨ ਵਾਂਗ) — ਮਹਿੰਗੀ ਐਗ੍ਰੀਗੇਸ਼ਨਸ ਲਈ ਆਦਰਸ਼ ਜੋ ਅਕਸਰ ਕਿਊਰੀ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

## Refreshing (ਸਟੋਰ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ)

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

ਤੁਹਾਨੂੰ ਡੇਟਾ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਲਈ **refresh** ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। `REFRESH ... CONCURRENTLY` (ਇੱਕ ਯੂਨਿਕ ਇੰਡੈਕਸ ਦੀ ਲੋੜ ਹੋ ਰਹੀ) ਸਮਕਾਲੀ ਪੜ੍ਹਨ ਨੂੰ ਬਲਾਕ ਕੀਤੇ ਬਿਨਾ ਅਪਡੇਟ ਕਰਦਾ ਹੈ — ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਮਹੱਤਵਪੂਰਨ।

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

## ਟ੍ਰੇਡ-ਆਫ

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

## ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

Materialized views PostgreSQL ਲਈ ਇੱਕ ਮੁੱਲਵਾਨ ਫ਼ੀਚਰ ਹਨ **ਪਰਫੋਰਮੈਂਸ ਅਨੁਕੂਲਨ** ਲਈ — ਇਹ ਮਹਿੰਗੀ ਕਿਊਰੀਜ਼ ਲਈ ਇੱਕ ਇਨ-ਡਾਟਾਬੇਸ ਕੈਸ਼ਿੰਗ ਮਕੇਨਿਜ਼ਮ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਉਨ੍ਹਾਂ ਨੂੰ ਸਮਝਣਾ ਮਹਿੰਗੀ, ਵਾਰ-ਵਾਰ-ਚਲਣ ਵਾਲੀ ਕਿਊਰੀਜ਼ ਦੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਲਈ ਵਜ਼ਨਯੋਗ ਹੈ।

ਮੂਲ ਮੁੱਲ ਮਹਿੰਗੀ ਕਿਊਰੀਜ਼ (ਜਟਿਲ ਐਗ੍ਰੀਗੇਸ਼ਨਸ, ਭਾਰੀ ਜੋਇਨਸ) ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਪੂਰਵ-ਗਣਨਾ ਕਰਨਾ ਅਤੇ ਸਟੋਰ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਤੇਜ਼ ਹੋ (ਇੱਕ ਟੇਬਲ ਨੂੰ ਕਿਊਰੀ ਕਰਨ ਵਾਂਗ) ਬਜਾਏ ਹਰ ਵਾਰ ਮਹਿੰਗੀ ਕਿਊਰੀ ਨੂੰ ਮੁੜ-ਚਲਾਉਣ ਦੇ — ਜੋ ਡੈਸ਼ਬੋਰਡਾਂ, ਰਿਪੋਰਟਸ, ਅਤੇ ਐਨਾਲਿਟਿਕਸ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਅਨੁਕੂਲਨ ਹੈ ਜਿੱਥੇ ਇੱਕੋ ਭਾਰੀ ਕਿਊਰੀ ਵਾਰ-ਵਾਰ ਚਲਦੀ ਹੈ।

ਮੂਲ **ਟ੍ਰੇਡ-ਆਫ** ਨੂੰ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: materialized views ਤੇਜ਼ ਪੜ੍ਹਨ ਦਿੰਦੇ ਹਨ ਪਰ ਡੇਟਾ **ਬਾਸੀ** ਹੈ refresh ਨੂੰ ਜਦ ਤੱਕ (ਅਤੇ ਇਹ ਸਟੋਰੇਜ ਖਰਚ ਕਰਦੇ ਹਨ), ਇਸ ਲਈ ਇਹ ਇੱਕ ਕੈਸ਼ਿੰਗ ਫੈਸਲਾ ਹੈ ਉਸ ਡੇਟਾ ਲਈ ਜਿਸ ਨੂੰ ਰਿਅਲ-ਟਾਈਮ ਤਾਜ਼ਗੀ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਉਨ੍ਹਾਂ ਨੂੰ **refresh** ਕਰਨਾ ਜਾਣਨਾ — ਖ਼ਾਸ ਤੌਰ ਤੇ `REFRESH ... CONCURRENTLY` (ਜੋ ਪੜ੍ਹਨ ਨੂੰ ਬਲਾਕ ਕੀਤੇ ਬਿਨਾ ਅਪਡੇਟ ਕਰਦਾ ਹੈ, ਪ੍ਰੋਡਕਸ਼ਨ ਉਪਲਬਧਤਾ ਲਈ ਮਹੱਤਵਪੂਰਨ, ਇੱਕ ਯੂਨਿਕ ਇੰਡੈਕਸ ਦੀ ਲੋੜ) — ਅਤੇ refresh ਰਣਨੀਤਿਆਂ (ਇੱਕ ਸ਼ਿਡਯੂਲ ਦੁਆਰਾ cron/pg_cron, ਜਾਂ ਡੇਟਾ ਤਬਦੀਲੀ ਦੇ ਬਾਅਦ) ਪ੍ਰਾਹਬਿਕ ਗਿਆਨ ਹੈ ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰਭਾਵੀ ਢੰਗ ਨਾਲ ਵਰਤਣ ਲਈ।

**Materialized views ਕਦੋਂ ਵਰਤਣੇ ਹਨ** ਇਹ ਸਮਝਣਾ (ਮਹਿੰਗੀ, ਵਾਰ-ਵਾਰ-ਚਲਣ ਵਾਲੀ ਕਿਊਰੀਜ਼ ਸਲਾਕਸ ਦਾ ਸਹਣਸ਼ੀਲ — ਡੈਸ਼ਬੋਰਡਸ, ਐਨਾਲਿਟਿਕਸ) ਬਨਾਮ ਕਦੋਂ ਨਹੀਂ (ਰਿਅਲ-ਟਾਈਮ ਸਟੀਕਤਾ ਦੀ ਲੋੜ ਵਾਲਾ ਡੇਟਾ) ਧਾਰਨਯੋਗ ਫੈਸਲੇ-ਲੈਣ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਕਿਉਂਕਿ ਮਹਿੰਗੀ ਬਾਰ-ਬਾਰ ਕਿਊਰੀਜ਼ ਇੱਕ ਅਸਲ ਪਰਫੋਰਮੈਂਸ ਸਮੱਸਿਆ ਹਨ, ਅਤੇ ਕਿਉਂਕਿ materialized views ਇੱਕ ਪ੍ਰਭਾਵੀ ਇਨ-ਡਾਟਾਬੇਸ ਕੈਸ਼ਿੰਗ ਹੱਲ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ (ਪੂਰਵ-ਗਣਨਾ ਕੀਤੇ, ਇੰਡੈਕਸ ਕਰਨ ਯੋਗ ਨਤੀਜੇ) ਵਿਸ਼ੱਖ ਤਾਜ਼ਗੀ/ਗਤੀ ਟ੍ਰੇਡ-ਆਫ ਦੇ ਨਾਲ, ਉਨ੍ਹਾਂ ਨੂੰ ਸਮਝਣਾ — ਉਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, refreshing (ਖ਼ਾਸ ਤੌਰ ਤੇ ਸਮਕਾਲੀ), ਟ੍ਰੇਡ-ਆਫ, ਅਤੇ ਢੁਕਵਿੱਖ ਵਰਤੋਂ — ਮੁੱਲਵਾਨ, ਲਾਗੂ-ਪ੍ਰਾਸੰਗਿਕ PostgreSQL ਗਿਆਨ ਹੈ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਕਿਊਰੀਜ਼ ਦੀ ਪਰਫੋਰਮੈਂਸ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਲਈ, ਇੱਕ ਆਮ ਲੋੜ ਜਿੱਥੇ materialized views ਇੱਕ ਸਾਫ, ਬਿਲਤ-ਇਨ ਹੱਲ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ।