VACUUM dọn 20000 dead tuple về 0 nhưng bảng vẫn đúng 712kB — nó đánh dấu chỗ trống để tái dùng chứ không trả đĩa. Tôi tưởng VACUUM hỏng vì nhìn kích thước file, hóa ra phải nhìn n_dead_tup. VACUUM FULL mới nén còn 8kB nhưng khóa bảng — hai lệnh gần tên mà khác hẳn tác động.
GROUP BY 100 nhóm trên 2 triệu hàng dùng HashAggregate chỉ 24kB; nhưng GROUP BY 2 triệu nhóm phân biệt làm nó tràn 62MB ra đĩa. Tôi suýt kết luận 'GROUP BY nhẹ RAM bất kể bảng lớn'. Bộ nhớ tính theo SỐ NHÓM phân biệt, không phải số hàng — và đó cũng là cái bẫy của COUNT(DISTINCT).
Tìm tài liệu chứa một từ trên 200k dòng: không index 141ms, một B-tree cũng 141ms (bị bỏ qua hoàn toàn), nhưng GIN chỉ 0,28ms — nhanh 500 lần. B-tree không hiểu toán tử 'chứa từ'. Loại index phải khớp phép toán truy vấn, không chỉ khớp cột — và EXPLAIN là trọng tài.
Bài kết sê-ri Cơ sở dữ liệu: quy trình tối ưu đúng là đo trước, đọc kế hoạch thật, sửa một thứ, đo lại. Một vòng trọn vẹn: WHERE khach=X quét cả 2 triệu hàng (17 ms) chỉ để tìm 40; EXPLAIN chỉ thẳng, thêm index, đo lại 0,15 ms — nhanh 113 lần. Không đoán, không cãi — đo là xong.
Tìm một email trong bảng 1 triệu hàng: không index quét 7353 trang mất 14ms; có index đọc 4 trang mất 0,034ms — nhanh 400 lần, đọc ít 1800 lần. Nhưng tôi suýt khoe 'nhanh 1600 lần' vì đọc nhầm 'cost' như thời gian. Cost là ước lượng của planner, actual time mới là đồng hồ. Bài mở đầu sê-ri Cơ sở 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.