Các tính năng mới của bộ lập kế hoạch truy vấn trong Postgres 16

 (citusdata.com)
1 điểm bởi GN⁺ 2024-02-11 | 1 bình luận | Chia sẻ qua WhatsApp

Các tính năng mới của bộ lập kế hoạch truy vấn trong PostgreSQL 16

  • PostgreSQL 16 mang đến nhiều cải tiến cho bộ lập kế hoạch truy vấn, giúp nhiều truy vấn SQL chạy nhanh hơn so với các phiên bản trước.
  • Có thể xem các cải tiến của bộ lập kế hoạch này trong ghi chú phát hành PG16, nhưng vì mỗi bản phát hành PostgreSQL có rất nhiều thay đổi nên khó có thể cung cấp giải thích chi tiết cho từng thay đổi.
  • Bài viết blog này cung cấp phân tích chuyên sâu về 10 cải tiến trong bộ lập kế hoạch truy vấn của PostgreSQL 16, kèm theo so sánh đầu ra của bộ lập kế hoạch giữa PG15 và PG16 và các ví dụ về những gì đã thay đổi.

10 cải tiến của bộ lập kế hoạch truy vấn trong PostgreSQL 16

  • Sắp xếp tăng dần: Được giới thiệu lần đầu trong PostgreSQL 13, sắp xếp tăng dần tận dụng trường hợp một phần tập kết quả đã được sắp xếp theo một hoặc nhiều cột đứng trước, và chỉ thực hiện sắp xếp cho các cột còn lại.
  • Tổng hợp sử dụng dữ liệu đã sắp xếp: Bộ lập kế hoạch truy vấn của PostgreSQL 16 giờ đây cố gắng tạo kế hoạch cung cấp các hàng cho nút tổng hợp theo thứ tự đã được sắp xếp.
  • Memoization: Nút kế hoạch memoization, lần đầu được giới thiệu trong PostgreSQL 14, hoạt động như một lớp bộ nhớ đệm để tránh tra cứu các giá trị trùng lặp.
  • Anti join: PostgreSQL 16 cho phép băm bảng nhỏ hơn khi thực hiện anti join.
  • Parallel hash join: PostgreSQL 16 hỗ trợ parallel hash join cho các kiểu FULL và RIGHT join.
  • Tối ưu hóa hàm cửa sổ: PostgreSQL 16 cho phép sử dụng các hàm cửa sổ nhanh hơn ở chế độ ROWS so với chế độ RANGE.
  • Tối ưu hóa hàm cửa sổ luôn tăng: PostgreSQL 16 mở rộng tối ưu hóa cho các hàm cửa sổ như ntile(), cume_dist(), percent_rank().
  • Loại bỏ join trên bảng phân vùng: PostgreSQL 16 cho phép tối ưu hóa loại bỏ LEFT JOIN trên bảng phân vùng.
  • Sử dụng Limit cho truy vấn DISTINCT: Bộ lập kế hoạch truy vấn của PostgreSQL 16 không bao gồm nút kế hoạch để khử trùng lặp trong kết quả khi có thể phát hiện rằng tất cả các hàng đều chứa cùng một giá trị.
  • Nới lỏng quy tắc cho Merge Join: Bộ lập kế hoạch truy vấn của PostgreSQL 16 khi xem xét Merge Join sẽ kiểm tra xem ít nhất một cột đứng trước đã được sắp xếp đúng hay chưa, thay vì yêu cầu thứ tự hàng phải khớp hoàn toàn chính xác.

Ý kiến của GN⁺

  • Các cải tiến của bộ lập kế hoạch truy vấn trong PostgreSQL 16 đóng vai trò quan trọng trong việc nâng cao hiệu năng cơ sở dữ liệu. Đặc biệt, các tính năng như sắp xếp tăng dần và memoization giúp thực thi các truy vấn phức tạp hiệu quả hơn.
  • Những cải tiến này sẽ rất hữu ích với các nhà phát triển và quản trị viên cơ sở dữ liệu sử dụng PostgreSQL, đặc biệt trong các hệ thống xử lý dữ liệu quy mô lớn, nơi có thể cảm nhận rõ mức cải thiện hiệu năng.
  • Nỗ lực đổi mới và cải tiến liên tục của cộng đồng PostgreSQL đang thúc đẩy sự phát triển của công nghệ cơ sở dữ liệu mã nguồn mở, từ đó mang lại các giải pháp quản lý dữ liệu tốt hơn cho người dùng và doanh nghiệp.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-02-11
Ý kiến Hacker News
  • Có ý kiến cho rằng sẽ tốt hơn nếu bộ lập kế hoạch truy vấn của Postgres có thể lập kế hoạch lại truy vấn ngay trong lúc thực thi. Do thiếu thông tin về phân bố dữ liệu, có thể hình thành kế hoạch truy vấn kém hiệu quả, từ đó ảnh hưởng lớn đến thời gian chạy. Nếu truy vấn diễn ra chậm hơn dự kiến, sẽ cần một tính năng lập kế hoạch lại truy vấn dựa trên thông tin tiến độ hiện tại. Tuy nhiên, vì Postgres hỗ trợ truy vấn streaming, việc thay đổi kế hoạch giữa chừng khi đang thực thi sẽ đòi hỏi thay đổi hạ tầng đáng kể.
  • Có người dùng cho biết họ sử dụng explain.dalibo.com và www.pgexplain.dev làm công cụ trực quan hóa truy vấn. Cả hai công cụ đều cho ra kết quả đầu ra tương tự nhau.
  • Có ý kiến rằng cải tiến bộ lập kế hoạch truy vấn là phần quan trọng trong cơ sở dữ liệu, nhưng thường chỉ trở nên dễ nhận thấy khi nó không hoạt động như mong muốn. Họ cũng chia sẻ kinh nghiệm rằng trình biên dịch JIT (Just-In-Time) trong các phiên bản Postgres mới nhất có vẻ chưa đủ vững về heuristic tại thời điểm sử dụng, và có thể làm chậm với dữ liệu nhỏ, nên tốt hơn là tắt JIT đi.
  • Có ý kiến thắc mắc những thay đổi này thực sự phát huy hiệu quả thường xuyên đến mức nào trong các truy vấn thực tế, đặc biệt là thay đổi "dùng Limit thay cho DISTINCT khi có thể" có trường hợp nào thực sự được áp dụng hay không. Đồng thời cũng đặt câu hỏi liệu các nhà phát triển Postgres có thông tin về điều này hay không.
  • Có ý kiến cho rằng sẽ hay nếu có một "strict mode" dành cho việc kiểm thử ứng dụng. Ở chế độ này, nếu không có index nào có thể cải thiện truy vấn thì hệ thống sẽ trả về lỗi, và có thể tạo các index cần thiết thông qua lệnh "CREATE INDICES FOR <sql>". Ngoài ra, cũng có đề xuất về chế độ tự động tạo index cho mục đích phát triển và sử dụng tương tác.
  • Một người dùng kể rằng bạn của họ làm DBA Microsoft cho các doanh nghiệp vừa và nhỏ, và cho rằng không thể làm các tác vụ nghiêm túc với Postgres. Người này còn nói họ ngạc nhiên khi biết Postgres không có bộ lập kế hoạch truy vấn, nhưng đó là thông tin sai. Có câu hỏi về mức độ đáng tin của tuyên bố rằng MSSQL có thể xử lý khối lượng công việc lớn hơn Postgres.
  • Có người đặt câu hỏi vì sao Postgres không triển khai hints.
  • Có câu hỏi vì sao tính năng do Citus Data công bố lại xuất hiện ở nơi khác thay vì trên postgresql.org, và liệu đó là tính năng trả phí hay là một tiện ích bổ sung mã nguồn mở.
  • Có câu hỏi về thời điểm Postgres có thể dùng index để tăng tốc truy vấn IS NOT DISTINCT FROM.
  • Một bình luận đã bị báo cáo nên bị gắn cờ.