Nạp 100.000 dòng bằng INSERT từng dòng mất 8,5 giây, suýt kết luận 'ghi vào CSDL vốn chậm'. Nhưng COPY nạp đúng 100.000 dòng đó chỉ 62ms — nhanh 137 lần, cùng dữ liệu, cùng độ bền. Cái chậm không phải việc ghi mà là mỗi dòng một commit và mỗi câu một lần parse. Đo bốn cách nạp, và tiền thời gian thật đi đâu.
Bật synchronous_commit=off thấy tps gấp đôi, suýt kết luận 'cứ tắt cho nhanh'. Nhưng đó là đánh đổi độ bền. Đo lại: 8 luồng sync=on nhờ group commit đạt 37689 tps — còn cao hơn sync=off một luồng, mà vẫn bền nguyên. Mỗi commit là một fsync, và fsync mới là nút cổ chai thật; cách gỡ nó không phải bỏ nó.
Theo phản xạ, tôi lao vào tối ưu truy vấn chậm nhất (23ms một lần). Nhưng nó là báo cáo chạy 2 lần — tổng chỉ 47ms. Trong khi một truy vấn tra index chỉ 0,0075ms mỗi lần, gọi 100000 lần, ngốn 754ms — gấp 16 lần. pg_stat_statements xếp theo TỔNG thời gian mới lộ thủ phạm thật: chi phí = mỗi lần × tần suất.
Tưởng 2 worker (3 tiến trình) thì quét nhanh 3 lần, đo ra chỉ 2,6 lần; 4 worker chỉ 3,2 lần. Song song không nhân tuyến tính vì bước Gather, phần tuần tự và cái đĩa dùng chung (định luật Amdahl). Và xin 6 worker chỉ được 4 — planner cấp theo cỡ bảng; bảng nhỏ thì PostgreSQL chẳng thèm song song. Khi nào một index thắng xa việc thêm worker.
Mang niềm tin cũ 'CTE là hàng rào tối ưu, luôn chậm hơn subquery', tôi viết CTE thường rồi ngồi đợi nó chậm. Đo ra nhanh y hệt subquery — 0,134ms, index scan — vì từ PG12 CTE được inline. Chỉ khi ép AS MATERIALIZED thì hàng rào cũ mới trở lại: 95ms, chậm 720 lần cho cùng logic. Vì sao một luật hiệu năng hết hạn theo phiên bản.
Tin lời khuyên kinh điển 'subquery chậm, viết lại thành JOIN'. Đo ngược: IN và EXISTS ra kế hoạch y hệt (semi join), và semi join đó nhanh gấp 10 lần JOIN+DISTINCT của tôi — vì DISTINCT nối cả triệu cặp rồi mới khử trùng. Nhãn 'subquery hay join' gần như không quyết định tốc độ; cái quyết định là việc truy vấn thật sự cần làm, đọc được trong EXPLAIN.