Đư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.
Ba khái niệm topic–partition–offset thường được vẽ bằng hình hộp và mũi tên. Tôi mở thẳng thư mục dữ liệu trên đĩa ra xem, và vấp phải một cái bẫy về key mà không hình vẽ nào cho thấy: hai partition rỗng hoàn toàn, thêm partition cũng chẳng chữa.
Tắt synchronous_commit cho 3,42 lần thông lượng. Tắt fsync không nhanh hơn chút nào — mà rủi ro thì thuộc một loại khác hẳn. Tôi đo cả bốn mức độ bền, và chỉ ra vì sao hai cái núm trông giống nhau thật ra là hai canh bạc rất khác nhau.
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.
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.
Ai cũng bảo 'acks=0 nhanh nhất'. Tôi đo thì thấy nó còn chậm hơn acks=1 5%. Chỉ acks=all mới thật sự tốn — mất nửa thông lượng. Và đây là thứ nửa đó mua được: sự thật, đúng lúc cụm đang hỏng.