Tắt fsync (synchronous_commit=off) chỉ nhanh gấp 2 lần trong đo của tôi — vì đĩa container là đĩa ảo nhanh; trên ổ cứng thật nó nhanh gấp hàng chục lần. WAL là thứ làm COMMIT bền, fsync là cái giá, và cái giá đó phụ thuộc hoàn toàn vào tốc độ đĩa. Gộp 3000 hàng vào 1 giao dịch = 1 fsync, nhanh gấp trăm lần.
Cost một seq scan = 5406 trang × 1.0 + 1 triệu hàng × 0.01 = 15406.00, khớp EXPLAIN đến từng số lẻ. Tôi tưởng cost cố định theo dữ liệu; nhưng đổi random_page_cost là planner đổi kế hoạch dù dữ liệu y nguyên. Cost là đầu ra của một mô hình với tham số phần cứng, không phải mili giây, không phải bất biến.
malloc 500MB làm VSZ tăng 512MB nhưng RSS vẫn 1MB — RAM thật chỉ tốn khi chạm trang. calloc 500MB cũng RSS ~1MB tới khi ghi (mẹo trang-zero chung). Vì sao cột VIRT khổng lồ trong top không phải thứ đáng lo, còn cột RES mới gây OOM.
Một hàng 8 byte dữ liệu (2 int) tưởng 1024 hàng/trang 8KB, đo thật chỉ 226 — vì mỗi tuple còn cõng 23 byte header MVCC + con trỏ + đệm = 36 byte. Tôi nhẩm phép chia mà quên chi phí cố định mỗi hàng. Mổ trang thật bằng pageinspect: gần 78% mỗi hàng hẹp là overhead, không phải dữ liệu.
Index chỉ có cột a đọc 103 trang (phải nhảy heap lấy b); index phủ (a) INCLUDE (b) cắt còn 4 trang, Heap Fetches=0 — nhưng CHỈ sau khi VACUUM cập nhật visibility map. Tôi tưởng INCLUDE hỏng, hóa ra quên VACUUM. Vì sao index-only scan của PostgreSQL phụ thuộc VACUUM.
UPDATE một cột không sửa tại chỗ: ctid đổi từ (0,1) sang (0,2), bản cũ thành dead tuple. Tôi tưởng UPDATE ghi đè giá trị, bảng giữ nguyên; đo ra một hàng UPDATE 10.000 lần làm bảng phình từ 8KB lên 360KB với 10.000 xác chết. Đây là MVCC — mỗi thay đổi để lại một phiên bản cũ, và vì sao đọc-ghi đồng thời mượt.