full_page_writes tạo ra full-page image trong WAL (chống torn page); wal_compression nén chúng lại. Đo thật: bật wal_compression giảm WAL 17-30% tuỳ độ nén của dữ liệu, FPI vẫn còn nên vẫn an toàn. Tắt full_page_writes giảm 35% nhưng bỏ hẳn chống torn page — gần như không bao giờ nên làm. 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.
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.
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_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.
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.