work_mem là RAM tối đa cho mỗi thao tác sort hoặc hash. Đo thật: sort 2 triệu dòng tràn 35 MB ra đĩa với work_mem nhỏ, làm trong RAM khi đủ; hash join chia 16 batch. Nhưng nó là per-operation per-connection nên đặt quá lớn có thể hết bộ nhớ. Cách tính an toàn. PostgreSQL 16.
maintenance_work_mem là RAM cho VACUUM, CREATE INDEX, REINDEX — tách khỏi work_mem và đặt cao hơn được. Đo thật: đủ RAM giữ danh sách dead tuple thì VACUUM chỉ quét index 1 lần thay vì 58 lần; nhưng tác dụng lên CREATE INDEX lại khiêm tốn. Cách đặt an toàn. PostgreSQL 16.
effective_cache_size không cấp phát bộ nhớ — nó chỉ là con số cho planner đoán chi phí Index Scan lặp lại. Đo thật: cùng một truy vấn, đặt 4MB planner quét tuần tự 5 triệu dòng mất 408 ms, đặt 32GB planner chọn Nested Loop + Index Scan 15,8 ms — nhanh gấp 26 lần. Vì sao mặc định 4GB thường quá thấp. PostgreSQL 16.
random_page_cost là tỉ số nói với planner đọc trang ngẫu nhiên đắt gấp mấy lần đọc tuần tự. Mặc định 4.0 hợp ổ cứng cơ HDD (thời gian seek), nhưng quá cao với SSD. Đo thật: cùng truy vấn khớp 1% dữ liệu, rpc=4.0 quét tuần tự cả bảng mất 84 ms, rpc=1.1 dùng index còn 7 ms — nhanh gấp 12 lần. Và cạm bẫy hạ quá tay. PostgreSQL 16.
effective_io_concurrency cho phép Bitmap Heap Scan nạp trước nhiều trang heap song song bằng posix_fadvise. Mặc định 1 là quá thấp cho SSD (nên 200-300). Nhưng đo thật trên container đã cache: eic=1 và eic=200 cho thời gian y hệt — vì prefetch chỉ che được độ trễ đọc đĩa THẬT. Bài học về cách benchmark tham số này cho đúng. PostgreSQL 16.
Mọi thay đổi ghi vào WAL trước để đảm bảo độ bền; checkpoint dồn các trang bẩn ra đĩa. Đo thật: cùng một UPDATE 100k dòng sinh 48 MB WAL ngay sau checkpoint (2606 full-page image) nhưng chỉ 28 MB khi lặp lại — chênh 20 MB là chi phí full-page image. Và cách đọc checkpoints_req để biết max_wal_size quá nhỏ. PostgreSQL 16.