Nạp dữ liệu là việc ai cũng phải làm và ít ai đo. Tôi nạp cùng một triệu dòng bằng năm cách, và tìm ra rằng cách nhanh nhất không phải cách đáng khuyên nhất — cú tăng 40 lần nằm ở gộp lô, thứ chạy được ở mọi nơi COPY không dùng đượ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.
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.
Đư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.
Ràng buộc là cách rẻ nhất để dữ liệu không hỏng, nhưng 'rẻ' là từ định tính. Tôi gán số cho từng loại: CHECK và NOT NULL gần như miễn phí, khoá ngoại làm chèn chậm 6,2 lần — và cái bẫy lớn nhất là chi phí của nó hiện ra ở một thao tác bạn không ngờ tới.
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.