Một truy vấn chạy 8 giây. Bạn đi theo thứ tự nào để sửa?

Chỗ đọc kế hoạch cần biết nhìn cái gì. Con số quan trọng nhất không phải cost mà là chênh lệch giữa rows ước lượng và actual rows — lệch 100 lần nghĩa là planner đang ra quyết định dựa trên thông tin sai, và mọi index bạn thêm sau đó có thể vẫn không được dùng. Buffers cho biết lượng dữ liệu thật sự đọc, và đó là đại lượng tương quan chặt nhất với thời gian.

Có một loại vấn đề rất hay bị bỏ sót: truy vấn nhanh khi chạy tay nhưng chậm trong ứng dụng. Nguyên nhân thường là generic plan của prepared statement — Postgres sau năm lần thực thi sẽ chuyển sang một kế hoạch chung không phụ thuộc tham số, và với dữ liệu lệch thì kế hoạch chung đó tệ hơn hẳn. Kiểm tra bằng cách EXPLAIN chính prepared statement đó chứ không phải câu SQL đã thay tham số.

Ở bước “lấy ít dữ liệu hơn”, câu hỏi hay nhất là truy vấn này phục vụ màn hình nào. Rất thường thì nó SELECT * trên bảng có cột JSON lớn trong khi giao diện chỉ hiển thị ba trường; chỉ cần liệt kê đúng cột là lượng byte giảm mười lần và index-only scan trở nên khả thi. Đây là kiểu sửa vừa rẻ vừa hiệu quả nhất, và nó không cần thêm index nào.