PostgreSQL có đúng ba cách nối hai bảng. Tôi ép chạy cả ba trên cùng truy vấn để xem chúng chênh nhau bao nhiêu, tìm ra một dải mà lựa chọn của bộ tối ưu không phải nhanh nhất, và một lần thiếu thống kê làm truy vấn chậm 800 lần mà không báo lỗi.
Nhiều năm liền, WITH của PostgreSQL là một hàng rào tối ưu không chuẩn SQL nào đòi hỏi: điều kiện lọc bên ngoài không được đẩy vào trong. PostgreSQL 12 đổi điều đó. Tôi dựng cả hai phiên bản với dữ liệu giống hệt để đo, và chỉ ra vì sao 'sửa' một hành vi tình cờ lại là một thay đổi phá vỡ.
Chạy cùng bộ SQL trên H2 và PostgreSQL 16 để thấy chỗ chúng khác nhau, đo chi phí thật của việc khởi động container, và cách giữ test nhanh khi dùng CSDL thật.
JDBC từ đầu: PreparedStatement chặn injection bằng cách tách cú pháp khỏi dữ liệu, getInt trên cột NULL trả về 0, chèn hàng loạt nhanh gấp 74 lần, và setFetchSize bị bỏ qua trong im lặng nếu quên setAutoCommit(false).
Đo trên 500.000 bài tiếng Việt: GIN nhanh 754 lần khi từ khoá hiếm, chậm hơn cả LIKE khi từ khoá phổ biến. Và cách xử lý ba chuyện riêng của tiếng Việt: không có bộ tách từ, tìm không dấu, và bẫy IMMUTABLE khi đánh chỉ mục unaccent.
Chỉ mục phủ làm truy vấn nhanh 6,6 lần, nhưng có một điều kiện thứ hai gần như không ai nhắc: bản đồ trang khả kiến. Kế hoạch vẫn ghi Index Only Scan mà thời gian tăng gấp đôi — và con số cần nhìn là Heap Fetches, thứ chỉ hiện khi bạn chạy EXPLAIN ANALYZE.