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.
Bảng to gấp 10.000 lần (1k lên 10 triệu hàng) mà cây chỉ mục chỉ sâu thêm một tầng (2 lên 3), tìm một hàng vẫn đọc 6-7 trang. Tôi tưởng bảng gấp 100 lần thì tìm phải chậm hẳn — đo ra đường phẳng. Vì fanout ~360, chi phí tra cứu tăng theo log cơ số vài trăm, gần như đứng yên. Cỡ dữ liệu và chi phí tra cứu là hai thứ khác hẳn.
Trên hai cột trùng nhau, planner đoán 99 hàng còn thực tế 10000 — lệch 100 lần. 'rows' của EXPLAIN là ước lượng (không chạy), 'actual rows' của EXPLAIN ANALYZE mới là đo thật (có chạy). Chính khoảng cách giữa hai con số tố cáo planner đang đoán mù — và EXPLAIN ANALYZE chạy thật cả UPDATE/DELETE.
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.
Truy vấn chọn lọc (1% hàng) dùng index nhanh 4,7 lần; nhưng trên cột boolean 50% hàng, planner bỏ index chọn seq scan. Tôi tưởng 'có index thì phải dùng index'. Index chỉ giúp khi truy vấn trả về ít hàng — và một index chết còn âm thầm làm chậm mọi lần ghi.
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.