Đưa logic vào cơ sở dữ liệu là quyết định thiết kế, nhưng cũng là quyết định hiệu năng. Tôi đo cái giá của việc gọi hàm — PL/pgSQL chậm 7,2 lần so với viết thẳng — và tìm ra một mặc định làm chậm truy vấn gấp đôi mà không ai được cảnh báo.
max_connections = 500 là cấu hình phổ biến, và nó thường sai. Tôi đo xem một máy chủ thật sự phục vụ được bao nhiêu kết nối trước khi thêm nữa chỉ làm mọi thứ tệ đi — kèm ba chi phí của một kết nối mà ít ai cộng đủ.
Phần trước đo được thông lượng PostgreSQL đạt đỉnh ở đúng số lõi CPU. PgBouncer là câu trả lời khi ứng dụng có nhiều máy chủ — nó nhồi 300 client vào 17 kết nối. Nhưng chế độ transaction có một cái giá không phải hiệu năng: trạng thái phiên của một client rò sang client khác.
'Tỉ lệ trúng đệm phải trên 99%' là một trong những lời khuyên được lặp nhiều nhất về PostgreSQL. Tôi đo xem nó thật sự nói lên điều gì: 19.184 trang bị đánh dấu 'read' chỉ tốn 27,75 ms — 1,4 micro giây mỗi trang, tức tốc độ bộ nhớ, vì có một lớp đệm mà con số đó không nhìn thấy.
'Truy vấn tràn ra đĩa thì tăng work_mem' là lời khuyên có trong mọi bài tinh chỉnh PostgreSQL. Tôi đo nó trên ba loại thao tác và cả ba đều đi ngược — cấu hình có ghi tệp tạm lại nhanh hơn cấu hình chạy hết trong bộ nhớ, vì nút thắt không nằm ở dung lượng RAM.
WAL là nhật ký ghi trước, lý do PostgreSQL sống sót sau mất điện. Tôi đo nó sinh ra bao nhiêu cho mỗi thao tác, và tìm ra một cấu hình phổ biến làm mọi thứ tệ đi theo cách ngược đời: hạ giới hạn để tiết kiệm đĩa lại đóng một vòng lặp khiến tốn nhiều đĩa hơn.