Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
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.
LIMIT 20 OFFSET 1000 là cách phân trang ai cũng viết đầu tiên: đúng, ngắn, và chậm dần theo số trang — nhưng chậm bao nhiêu thì ít ai đo. Tôi đo, và đo cả một lỗi nghiêm trọng hơn chuyện chậm: OFFSET neo vào vị trí, mà vị trí thì đổi khi dữ liệu đổi.
pg_stat_statements trả lời 'truy vấn nào tốn nhất'. Các khung nhìn pg_stat_* trả lời câu khác: bảng nào, chỉ mục nào, bộ đệm đang làm gì. Tôi đo chúng nói gì, ba chỗ chúng im lặng — gồm một sự cố xoá sạch mọi bộ đếm — và một dự đoán của tôi bị bác bỏ.
Đư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.
'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.
Năm mươi lăm phần trước đo từng cơ chế riêng lẻ; phần này ghép lại thành một quy trình gỡ truy vấn chậm và chạy trên một sự cố dựng sẵn từ đầu tới cuối. Bất ngờ lớn nhất: chỉ mục bao phủ mà ai cũng nghĩ là nhanh nhất lại tệ thứ nhì, còn chỉ mục nhanh nhất cũng là chỉ mục nhỏ nhất.