PostgreSQL — Kiến trúc nội bộ

Port từ tài liệu HTML gốc — tương tác (tab INSERT/UPDATE/DELETE, layer, tooltip, mobile menu) được nối lại bằng React hooks.

🐘 Kiến trúc nội bộ PostgreSQL

Hướng dẫn chuyên sâu cho DevOps Engineers — Hiểu rõ luồng dữ liệu bên trong PostgreSQL, từ kết nối đến ổ đĩa, thông qua SQL Pipeline, MVCC, và các background processes.

🟢 Layer 1: Frontline 🔵 Layer 2: SQL Pipeline 🟣 Layer 3: Shared Memory ⚪ Layer 4: Workers 🟧 Layer 5: Disk

🏗️ Kiến trúc tổng quan — 5 Layers

PostgreSQL sử dụng kiến trúc process-based (mỗi kết nối = 1 process riêng). Dưới đây là 5 lớp từ client đến ổ đĩa. Các thành phần đánh dấu MỚI là những gì bạn có thể chưa biết.

Frontline 🟢 — Connection Handlers

▼

🌐 Client Applications (Web/App)

Ứng dụng của bạn kết nối tới PostgreSQL qua thư viện như psycopg2, pgjdbc, node-postgres...

🔄 pgbouncer (Connection Pooler)

Pool kết nối ở ngoài PostgreSQL. Giảm overhead của việc fork backend process. Pool mode: session / transaction / statement.

📡 Postmaster Listener Process

Process chính — lắng nghe kết nối mới, xác thực (pg_hba.conf), fork backend process. Nếu Postmaster chết → toàn bộ DB xuống.

port = 5432 | listen_addresses = '*'

⚙️ Backend Processes (1/connection)

Mỗi kết nối = 1 OS process riêng (không phải thread!). Chạy Parser → Analyzer → Planner → Executor bên trong.

max_connections = 100 (mặc định)

Fork process

SQL Processing Pipeline 🔵 MỚI — BẠN ĐANG THIẾU LỚP NÀY!

▼

📝 Parser MỚI

Chuyển SQL text → Parse Tree. Kiểm tra cú pháp (grammar) CHƯA kiểm tra semantics.

🔍 Analyzer / Semantic Rewrite MỚI

Kiểm tra bảng/cột tồn tại, quyền truy cập, resolve names. Output: Query Tree.

🧠 Planner / Optimizer MỚI

Cost-based optimization. Tính toán nhiều execution plan, chọn plan tối ưu nhất. Output: Plan Tree.

EXPLAIN ANALYZE SELECT ...

⚡ Executor MỚI

Thực thi Plan Tree, gọi storage engine functions: heap_insert(), heap_update(), heap_delete().

🔄 Transaction Manager MỚI

Gán xid (Transaction ID), quản lý BEGIN/COMMIT/ROLLBACK, đọc/ghi CLOG.

default_transaction_isolation = 'read committed'

🔒 Lock Manager MỚI

Table locks, row-level locks, advisory locks. Read KHÔNG cần lock nhờ MVCC.

deadlock_timeout = 1s | lock_timeout = 0

🧮 Local Buffer / Sort / Hash MỚI

Bộ nhớ cục bộ cho sort, hash join, bitmap. Vượt quá → spill to disk (temp_files).

work_mem = 4MB | maintenance_work_mem = 64MB

Đọc/ghi Shared Memory

Shared Memory 🟣 — Bộ nhớ dùng chung

▼

🟣 Shared Buffers

Data page cache (8KB/page). Đọc/ghi data đi qua đây trước khi disk.

shared_buffers = 128MB (mặc định), khuyến nghị: 25% RAM

🔴 WAL Buffers

Cache cho WAL records trước khi flush. Đảm bảo durability (ACID - D).

wal_buffers = -1 (tự động, thường = 1/32 shared_buffers)

🟡 CLOG / Commit Log MỚI

Track transaction status: committed / aborted / in-progress. 2 bit per xid. Quan trọng cho MVCC!

🟡 Subtrans MỚI

Subtransaction tracking cho SAVEPOINT. Cho phép ROLLBACK TO SAVEPOINT.

🟠 Free Space Map (FSM) MỚI

Track free space trong mỗi table page. INSERT dùng FSM để tìm page có chỗ trống nhanh chóng.

max_fsm_pages (tự động quản lý)

🟠 Visibility Map (VM) MỚI

Đánh dấu page all-visible / all-frozen. Giúp VACUUM nhanh hơn (Index-Only Scan cũng dùng VM).

Background processes

Auxiliary Workers ⚪ — Background Processes

▼

💾 Checkpointer

Flush dirty buffers → disk định kỳ. Tạo checkpoint. Ảnh hưởng recovery time.

checkpoint_timeout = 5min | max_wal_size = 1GB

✍️ Background Writer (bgwriter)

Dọn dirty buffers từ từ để giảm checkpoint spike. Giảm I/O burst.

bgwriter_delay = 200ms | bgwriter_lru_maxpages = 100

📝 WAL Writer

Flush WAL buffers → WAL files. Đảm bảo WAL records được ghi thường xuyên.

wal_writer_delay = 200ms

🧹 Autovacuum Launcher + Workers

Tự động VACUUM (dọn dead tuples) + ANALYZE (cập nhật thống kê). Launcher → fork workers.

autovacuum_max_workers = 3 | autovacuum_naptime = 1min

📡 WAL Sender MỚI

Gửi WAL records đến standby cho streaming replication. 1 process per standby.

wal_level = replica | max_wal_senders = 10

📊 Stats Collector MỚI

Thu thập thống kê cho pg_stat_activity, pg_stat_database, v.v.

track_activities = on | track_counts = on

📋 Syslogger MỚI

Ghi PostgreSQL log ra file. Hỗ trợ csvlog cho phân tích bên ngoài.

logging_collector = on | log_directory = 'log'

Flush / Persist

Disk Storage 🟧 — Persistent Storage

▼

💾 Data Files (pg_data/base/)

Tables, Indexes. Mỗi relation = 1+ file (split 1GB). Page size = 8KB.

pg_data/base//

📝 WAL Files (pg_data/pg_wal/)

Write-Ahead Log segments (16MB/segment). Ghi tuần tự, quan trọng cho recovery.

wal_segment_size = 16MB | min_wal_size = 1GB

📦 WAL Archive (PITR)

Lưu WAL segments đã filled. Dùng cho Point-In-Time Recovery.

archive_mode = on | archive_command = 'cp %p /archive/%f'

⚙️ Config Files

postgresql.conf (cấu hình), pg_hba.conf (auth), pg_ident.conf (user mapping).

⚙️ SQL Processing Pipeline — Chi tiết bên trong Backend Process

Khi 1 câu SQL được gửi đến PostgreSQL, nó đi qua 4 giai đoạn bên trong Backend Process. Đây là điều NHIỀU DevOps bỏ qua nhưng cực kỳ quan trọng để hiểu performance.

📨 Client gửi SQL: SELECT name, age FROM users WHERE age > 25;

📝 Giai đoạn 1: Parser

Phân tích cú pháp SQL text → Parse Tree (Cây cú pháp)

Input: Raw SQL text string

🔍 Giai đoạn 2: Analyzer / Semantic Rewrite

Kiểm tra semantics: bảng tồn tại? cột hợp lệ? quyền truy cập? → Query Tree

Input: Parse Tree

Output: Query Tree ✅

🧠 Giai đoạn 3: Planner / Optimizer

Cost-based optimization: tạo nhiều plan → tính cost → chọn plan tối ưu → Plan Tree

Input: Query Tree + pg_statistics

Output: Plan Tree 📋

⚡ Giai đoạn 4: Executor

Thực thi Plan Tree → gọi Storage Engine functions → trả kết quả về Client

Input: Plan Tree

Output: Result Set 📊 → Client

🔧 Ngoài SQL Pipeline ra, Backend Process còn chứa:

🔄 Transaction Manager

Gán xid cho mỗi txn, ghi CLOG khi commit/abort, enforce isolation level

🔒 Lock Manager

Quản lý table/row/advisory locks. Deadlock detection khi có conflict.

🧮 work_mem

Bộ nhớ cho sort, hash join, bitmap. Vượt quá → spill to temp files (chậm!)

💾 maintenance_work_mem

Bộ nhớ cho VACUUM, CREATE INDEX, ALTER TABLE. Mặc định 64MB.

📊 Logical Decoding

Phân tích WAL thành logical replication events (pgoutput, wal2json).

⚡ Plan Cache

Cache generic plan cho Prepared Statements. Giảm thời gian planning.

📋 Tóm tắt các stage và output của chúng:

Stage	Input	Output	Kiểm tra gì?	Xem bằng
Parser	SQL text	Parse Tree	Cú pháp (grammar only)	—
Analyzer	Parse Tree	Query Tree	Bảng, cột, quyền, type	—
Planner	Query Tree	Plan Tree	Cost estimation	`EXPLAIN`
Executor	Plan Tree	Result Set	Thực thi & I/O	`EXPLAIN ANALYZE`

🔍 MVCC Deep Dive — Multi-Version Concurrency Control

PostgreSQL sử dụng MVCC để cho phép nhiều transaction đọc/ghi đồng thời KHÔNG block nhau. Đây là concept quan trọng NHẤT để hiểu INSERT, UPDATE, DELETE hoạt động như thế nào.

📦 Cấu trúc Heap Tuple Header

Mỗi row trong PostgreSQL có 1 header 23 bytes chứa metadata về MVCC:

Trường	Ý nghĩa
t_xmin	Transaction ID tạo ra tuple này. PostgreSQL biết tuple nào do txn nào tạo.
t_xmax	Transaction ID xóa/cập nhật tuple. `0` = tuple còn sống (alive). Khác 0 = đã bị delete/update.
t_cid	Command ID trong transaction (thứ tự lệnh: 0, 1, 2...). Dùng cho visibility trong cùng 1 transaction.
t_ctid	Current Tuple ID = (block_number, offset). Sau UPDATE, old tuple t_ctid → new tuple. Đóng vai trò con trỏ.
infomask	Hint bits cache commit status trực tiếp trên tuple: HEAP_XMIN_COMMITTED, HEAP_XMAX_INVALID, v.v. Giảm CLOG lookup.
User Data	Dữ liệu thực tế (giá trị các cột). NULL bitmap nếu có null columns.

👁️ Quy tắc Visibility — Tuple có visible không?

Khi 1 transaction SELECT, PostgreSQL kiểm tra mỗi tuple:

✅ Tuple VISIBLE khi:

t_xmin là committed (người tạo đã commit) VÀ
(t_xmax = 0 HOẶC t_xmax chưa committed hoặc aborted)

❌ Tuple INVISIBLE khi:

t_xmin chưa committed (người tạo chưa commit) HOẶC
t_xmax đã committed (ai đó đã delete/update)

⚡ Hint Bits (infomask) — Tối ưu visibility check:

Thay vì lookup CLOG mỗi lần, PostgreSQL cache commit status trực tiếp trên tuple:
HEAP_XMIN_COMMITTED — xmin đã commit
HEAP_XMIN_INVALID — xmin aborted/rollback
HEAP_XMAX_COMMITTED — xmax đã commit (đã bị delete)
HEAP_XMAX_INVALID — xmax aborted (tuple vẫn alive)

🔑 Điểm mấu chốt:

READ không cần LOCK! Nhờ MVCC, SELECT chỉ đọc phiên bản tuple phù hợp với snapshot của transaction. Đọc KHÔNG chặn ghi và ghi KHÔNG chặn đọc.

🔗 Version Chain — Chuỗi phiên bản tuple sau nhiều UPDATE

Mỗi UPDATE tạo ra 1 phiên bản MỚI của tuple (old version vẫn giữ lại). t_ctid tạo thành chuỗi liên kết:

💀 Version 1 (Dead Tuple)

t_xmin=100t_xmax=105t_ctid → V2
name='Alice' (giá trị cũ)

t_ctid trỏ tới

💀 Version 2 (Dead Tuple)

t_xmin=105t_xmax=110t_ctid → V3
name='Alice B.' (giá trị cũ)

t_ctid trỏ tới

✅ Version 3 (Alive — Hiện tại)

t_xmin=110t_xmax=0t_ctid=(3,1)
name='Alice B. Chen' (giá trị hiện tại)

⚠️ Vấn đề: Version 1 & 2 là dead tuples — chúng VẪN chiếm chỗ trên disk! Autovacuum sẽ dọn chúng sau. Nếu autovacuum không chạy đủ nhanh → table bloat.

📝 Luồng hoạt động chi tiết — INSERT / UPDATE / DELETE

Click vào tab tương ứng để xem luồng chi tiết của từng thao tác. Mỗi bước được gắn với Layer cụ thể và mô tả chi tiết những gì diễn ra bên trong.

Client gửi câu INSERT SQL

Layer 1

Ứng dụng gửi INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com'); qua kết nối TCP/IP đến PostgreSQL.

Postmaster → Backend Process

Layer 1

Kết nối được routing đến backend process đang phục vụ client này. Nếu dùng pgbouncer, nó reuse backend process hiện có.

Parser → Parse Tree

Layer 2

Parser phân tích cú pháp SQL, tạo Parse Tree. Lúc này CHƯA kiểm tra table users có tồn tại không.

Analyzer → Query Tree

Layer 2

Kiểm tra semantics: table users tồn tại? Columns name, email hợp lệ? Type match? User có quyền INSERT? Output: Query Tree.

Planner → Plan Tree

Layer 2

Tạo execution plan: quyết định insert vào page nào (dùng FSM), cập nhật bao nhiêu index, cost estimation. Output: Plan Tree.

Executor → gọi heap_insert()

Layer 2

Executor thực thi plan, gọi hàm heap_insert() của storage engine.

Transaction Manager: Gán Transaction ID (xid)

Layer 2 — MVCC

Nếu chưa có active transaction, Transaction Manager gán 1 xid mới. xid này sẽ ghi vào t_xmin của tuple mới.

t_xmin = 742 (ví dụ xid hiện tại)

Lock Manager: Acquire Row-Level Lock

Layer 2

Lock target page/table để tránh conflict với concurrent inserts vào cùng page. Row-level lock nhẹ hơn table lock.

Kiểm tra FSM (Free Space Map) tìm page trống

Layer 3

PostgreSQL tra FSM để tìm page có đủ free space cho tuple mới. Nếu không tìm thấy → extend table file (thêm page mới).

Tạo Heap Tuple mới

Layer 2 — MVCC

Tạo tuple với header MVCC:

t_xmin = 742 (xid hiện tại)
t_xmax = 0 (tuple còn sống ✅)
t_ctid = (block, offset) của tuple này
infomask = HEAP_HASNULL | HEAP_XMIN_INVALID (chưa commit)

Ghi WAL Record (REDO record)

Layer 2

Tạo WAL record cho INSERT operation. WAL record chứa đủ thông tin để rebuild tuple nếu crash. Đây là Write-Ahead Log — ghi LOG TRƯỚC khi ghi DATA!

Tuple → Shared Buffers (mark buffer dirty)

Layer 3

Tuple được ghi vào Shared Buffers (KHÔNG phải trực tiếp disk). Buffer được đánh dấu dirty — chưa flush xuống disk.

Cập nhật FSM nếu page đầy

Layer 3

Nếu page không còn đủ free space sau insert → cập nhật FSM để các INSERT sau không scan page này nữa.

Cập nhật Indexes

Layer 2

Mỗi index trên table users cần insert entry mới cho tuple. Mỗi index insert cũng tạo WAL record riêng.

⚙️ Layer 4 — Background Processes (CHẠY NGOÀI query path)

WAL Writer: Flush WAL buffers → pg_wal/ (đảm bảo durability).
Checkpointer: Flush dirty buffers → Data Files (định kỳ, không phải ngay lập tức).
Background Writer: Giúp dọn dirty buffers từ từ, giảm checkpoint I/O spike.
Autovacuum: Chạy ANALYZE để cập nhật statistics cho planner.

Layer 5 — Disk (cuối cùng)

Layer 5

WAL: pg_wal/ — WAL records được flush (đảm bảo crash recovery).
Data: pg_data/base/.../table_file — dirty pages được flush bởi Checkpointer.

✅ Tóm tắt INSERT

INSERT = tạo tuple mới với t_xmin=xid, t_xmax=0 → ghi WAL → ghi Shared Buffers → cập nhật indexes → background processes flush to disk.
Tuple KHÔNG ghi trực tiếp disk. Mọi thứ đi qua Shared Buffers và WAL buffers trước.

Client gửi câu UPDATE SQL

Layer 1

UPDATE users SET name = 'Alice B. Chen' WHERE id = 42;

Postmaster → Backend Process

Layer 1

Routing đến backend process phục vụ kết nối hiện tại.

SQL Pipeline: Parser → Analyzer → Planner → Executor

Layer 2

Giống INSERT. Planner quyết định dùng index scan trên id để tìm tuple cũ. Executor gọi heap_update().

Tìm OLD tuple (qua index hoặc sequential scan)

Layer 2

Dùng index trên id để nhanh chóng tìm tuple có id=42 trong heap.

Kiểm tra visibility của old tuple

Layer 2 — MVCC

Kiểm tra t_xmin committed (tuple tồn tại) VÀ t_xmax = 0 hoặc chưa committed (tuple chưa bị ai delete). Nếu old tuple invisible → skip hoặc error.

Lock Manager: Acquire Row-Level Lock (FOR UPDATE)

Layer 2

Khóa row để tránh concurrent UPDATE/DELETE trên cùng tuple. Nếu bị lock bởi txn khác → CHỜ (hoặc timeout nếu lock_timeout set).

🔥 Quyết định quan trọng: HOT Update hay Regular Update?

🚀 HOT Update (Heap-Only Tuple)

Tất cả indexed columns KHÔNG đổi
New tuple fit vào cùng page
Old tuple t_ctid → new tuple
Không cần cập nhật indexes!
Chỉ 1 WAL record
Rất nhanh! ⚡

📝 Regular Update

Indexed columns CÓ đổi
HOẶC new tuple không fit cùng page
Old tuple: t_xmax = current xid
New tuple insert như INSERT mới
CẦN cập nhật TẤT CẢ indexes
Nhiều WAL records
Chậm hơn nhiều 🐢

Old tuple trở thành DEAD tuple

Layer 2 — MVCC

Update old tuple header:

t_xmax = 742 (xid hiện tại — đánh dấu "đã bị update bởi txn này")
t_ctid → (block, offset) của NEW tuple
infomask: HEAP_XMAX_INVALID ban đầu (chưa commit)

⚠️ Old tuple VẪN chiếm physical space trên disk! Nó chỉ được đánh dấu invisible.

Tạo NEW tuple (giống INSERT)

Layer 2 — MVCC

t_xmin = 742 | t_xmax = 0 | t_ctid = (block, offset)
User Data: name = 'Alice B. Chen' (giá trị mới)

WAL Record → Shared Buffers → Update Indexes

Layer 3

Giống INSERT: ghi WAL record (cho cả old + new tuple), ghi vào Shared Buffers, cập nhật indexes (trừ HOT update!).

⚙️ Layer 4 — Background Processes

Giống INSERT. Đặc biệt: Autovacuum sẽ dọn dead tuples cũ sau này.

Layer 5 — Disk

Layer 5

WAL → pg_wal/, Data pages → pg_data/base/ (do Checkpointer flush).

⚠️ Tóm tắt UPDATE — Điều quan trọng nhất

UPDATE = DELETE old tuple + INSERT new tuple dưới góc độ MVCC.

Old tuple KHÔNG bị xóa物理上! Nó trở thành dead tuple — vẫn chiếm space trên disk.
Autovacuum mới dọn dead tuples. Nếu autovacuum chậm → table bloat → performance giảm.

💡 Tip cho DevOps: Monitor pg_stat_user_tables.dead_tup_count và n_dead_tup để biết khi nào cần VACUUM.

Client gửi câu DELETE SQL

Layer 1

DELETE FROM users WHERE id = 42;

Postmaster → Backend Process

Layer 1

Routing đến backend process.

SQL Pipeline: Parser → Analyzer → Planner → Executor

Layer 2

Planner quyết định dùng index scan trên id. Executor gọi heap_delete().

Tìm OLD tuple

Layer 2

Dùng index trên id để tìm tuple id=42 trong heap. (Nếu DELETE không có WHERE → full table scan)

Kiểm tra visibility của old tuple

Layer 2 — MVCC

Giống UPDATE: kiểm tra t_xmin committed và t_xmax chưa committed. Nếu tuple đã bị delete bởi txn khác → skip.

Lock Manager: Acquire Row-Level Lock

Layer 2

Khóa row để tránh concurrent modification.

🔥 Đánh dấu tuple as DELETED (KHÔNG xóa vật lý!)

Layer 2 — MVCC

Chỉ cập nhật header của tuple:

t_xmax = 742 (xid hiện tại — "đã bị delete bởi txn này")
Tuple data: VẪN CÒN NGUYÊN! Không bị xóa!

💀 Tuple trở thành dead tuple. Nó invisible với tất cả transactions bắt đầu SAU txn hiện tại.

Ghi WAL Record

Layer 2

WAL record cho DELETE — ghi log TRƯỚC khi modify data page trong Shared Buffers.

Update Shared Buffers (mark buffer dirty)

Layer 3

Page chứa tuple được đánh dấu dirty. Tuple header đã được update trong buffer.

Cập nhật Indexes (mark entries dead)

Layer 2

Index entries KHÔNG bị xóa ngay! PostgreSQL đặt hint LP_DEAD trên index entry. Cleanup thực sự xảy ra khi:

• Next index scan gặp dead entry → xóa ngay
• VACUUM → bulk cleanup dead index entries

⚙️ Layer 4 — Background Processes

WAL Writer: Flush WAL → disk.
Checkpointer: Flush dirty pages → Data Files.
Autovacuum: QUAN TRỌNG NHẤT cho DELETE! Autovacuum dọn dead tuples, reclaim space, update FSM, update VM, cleanup dead index entries.

Layer 5 — Disk

Layer 5

WAL → pg_wal/, Dirty pages → pg_data/base/ (checkpointer). Tuple data vẫn còn trên disk!

⚠️ Tóm tắt DELETE — Điều quan trọng nhất

PostgreSQL KHÔNG XÓA dữ liệu vật lý khi DELETE!

DELETE chỉ cập nhật t_xmax trên header. Tuple data vẫn nằm nguyên trên disk.

→ Space KHÔNG được reclaim ngay lập tức
→ Autovacuum mới dọn dead tuples và trả lại free space
→ Nếu autovacuum không chạy đủ nhanh → table bloat → disk full, queries chậm

💡 Monitor SQL:


SELECT relname, n_live_tup, n_dead_tup, last_vacuum, last_autovacuum

FROM pg_stat_user_tables WHERE n_dead_tup > 1000;

🆕 So sánh INSERT vs UPDATE vs DELETE

Hoạt động	t_xmin	t_xmax	Physical space	Index update	WAL records	Vacuum needed?
INSERT	Set xid	0	Tăng	Có	1+ per index	Không
UPDATE	Old: giữ, New: set xid	Old: set xid, New: 0	Tăng (new tuple)	Có* (trừ HOT)	2+ (old + new)	CÓ!
DELETE	Giữ nguyên	Set xid	Không đổi!	LP_DEAD hint	1 (heap only)	CÓ!

🆕 Thành phần MỚI — Những gì bạn đang thiếu

Dưới đây là tóm tắt các thành phần đã được thêm vào kiến trúc của bạn. Các mục này được đánh dấu MỚI trong toàn bộ trang.

Layer 2 — SQL Processing Pipeline (CẢ LỚP NÀY MỚI!)

Parser (Parse Tree)
Analyzer / Semantic Rewrite (Query Tree)
Planner / Optimizer (Plan Tree)
Executor (heap_insert/update/delete)
Transaction Manager (xid, CLOG)
Lock Manager (row/table locks)
Local Memory (work_mem, maintenance_work_mem)

Layer 3 — Shared Memory (thành phần mới)

CLOG / Commit Log — Track transaction status
Subtrans — Subtransaction tracking (SAVEPOINT)
Free Space Map (FSM) — Track free space in pages
Visibility Map (VM) — Track all-visible pages

Layer 4 — Background Processes (thành phần mới)

WAL Sender — Streaming replication
Stats Collector — pg_stat_* views
Syslogger — Log collection

MVCC Concepts (hoàn toàn mới)

Heap Tuple Header (t_xmin, t_xmax, t_ctid, infomask)
Visibility Rules (khi nào tuple visible/invisible)
Hint Bits (infomask optimization)
Version Chain (chuỗi phiên bản sau UPDATE)
Dead Tuples & Table Bloat
HOT Update (Heap-Only Tuple optimization)

MVCC & Operations (hiểu sâu INSERT/UPDATE/DELETE)

INSERT: tạo tuple mới, t_xmin=xid, t_xmax=0
UPDATE = DELETE old + INSERT new
DELETE: chỉ set t_xmax, KHÔNG xóa vật lý
Autovacuum dọn dead tuples
LP_DEAD hint trên index entries
WAL: Write-Ahead Log cho durability

Layer 5 — Thêm chi tiết

WAL Archive cho PITR
Page size = 8KB
WAL segment = 16MB
pg_data/base/ structure

🎯 Key Takeaways cho DevOps

1. SQL Pipeline là core

Mọi query đều qua Parser → Analyzer → Planner → Executor. EXPLAIN ANALYZE xem plan. Slow query? Kiểm tra planner trước!

2. DELETE không xóa dữ liệu

MVCC: DELETE chỉ set t_xmax. Autovacuum mới reclaim space. Không vacuum = table bloat = disk full.

3. HOT Update rất quan trọng

Nếu update column không có index → HOT update → không update index → nhanh hơn gấp nhiều lần. Thiết kế table với điều này trong đầu!

4. WAL đảm bảo durability

Mọi modification đều ghi WAL TRƯỚC. synchronous_commit = on (mặc định) = chờ WAL flush trước khi ACK client. Off = nhanh hơn nhưng có risk.

5. Background processes chạy silently

Checkpointer, bgwriter, autovacuum, WAL writer — tất cả chạy ngầm. Monitor chúng! Nếu autovacuum lag → database sẽ chậm dần.

6. Monitor dead tuples

pg_stat_user_tables.n_dead_tup — nếu quá cao → autovacuum không kịp → cần tune autovacuum parameters.

Đang tải diagram…