Ba tiến trình cùng mmap một file 90MB. Cộng RSS ba cái ra 270MB — gấp ba dung lượng thật, một con số bất khả. Cộng PSS ra 89MB, khớp RAM thật. Vì sao cộng cột RES trong top luôn thổi phồng bộ nhớ nhóm worker, và cột nào mới cộng đúng.
Cùng một vòng lặp: đo một lần ra 0,459ms nhưng đuôi tới 2,072ms (gấp 4 lần); -O2 gấp 2 tỉ vòng thành 0,000042ms (bất khả — trình biên dịch xóa vòng lặp). Bài chốt sê-ri Hệ điều hành: một phép đo là giả thuyết phải tra hỏi, không phải chân lý để tin — số quá đẹp đáng nghi ngang số quá xấu.
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.