Những điểm mới trong Postgres 19: phân tích sâu bản beta

 (snowflake.com)
1 điểm bởi GN⁺ 3 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Bản beta tích hợp sẵn REPACK CONCURRENTLY vào lõi cho cơ sở dữ liệu production quy mô lớn, cùng nhiều cải tiến rộng khắp về truy vấn đồ thị thuộc tính SQL, replication logic, VACUUM, hiệu năng, v.v.
  • Hỗ trợ gộp và tách partition cùng đồng bộ giá trị sequence, giúp thay đổi thiết kế và di chuyển dữ liệu khi đang vận hành trở nên dễ dàng hơn
  • Autovacuum được bổ sung worker song song và hệ thống điểm ưu tiên, cải thiện thông lượng và khả năng quan sát của tác vụ bảo trì
  • Với SQL/PGQ, có thể truy vấn dữ liệu hiện có dưới dạng đồ thị mà không cần từ bỏ mô hình quan hệ
  • Trọng tâm không phải một tính năng tiêu đề đơn lẻ mà là độ bao phủ rộng (breadth), với tiến bộ đồng thời trên toàn bộ ứng dụng, vận hành, hiệu năng và khả năng mở rộng

REPACK được tích hợp mặc định

  • Trong các môi trường vận hành lâu năm, nhu cầu thu hồi table bloat, viết lại bảng và tái tổ chức dữ liệu trong khi tránh các khóa đi kèm VACUUM FULL hoặc CLUSTER lặp lại thường xuyên
    • Đã có một hệ sinh thái extension để giải quyết vấn đề này, tiêu biểu là pg_repack đã lấp khoảng trống đó
  • Postgres 19 đưa lệnh REPACK vào lõi, bao gồm hỗ trợ REPACK CONCURRENTLY
    • Đây được kỳ vọng là tính năng mà người dùng production sẽ chú ý hơn so với những gì độc giả trung bình của release note có thể dự đoán

Partitioning thực dụng hơn

  • Postgres 19 bổ sung hỗ trợ gộp và tách partition
  • Chiến lược partitioning thường được chọn với thông tin chưa đầy đủ; khi workload, thời gian lưu giữ hoặc tốc độ tăng dữ liệu thay đổi, một số partition có thể phình to hoặc trở nên quá nhỏ
  • Khả năng tách/gộp giúp có dư địa để thiết kế tiến hóa theo thời gian mà không phải tái cấu trúc toàn bộ từ đầu
    • Gộp partition Q1 và Q2 thành một partition duy nhất: ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
    • Có ví dụ SPLIT PARTITION để tách partition Q3 theo từng tháng

Replication logic trưởng thành hơn

  • Replication logic hữu ích cho migration, upgrade, hệ thống reporting, di chuyển dữ liệu, replication chọn lọc, high availability và workflow vận hành
  • Cải tiến lớn nhất là đồng bộ giá trị sequence, giúp subscriber khớp với publisher tốt hơn
    • Khi replicate mà không có trạng thái sequence, dữ liệu vẫn được di chuyển nhưng sau cutover có thể phát sinh vấn đề do ID được tạo tiếp theo bị lệch
    • Bổ sung hỗ trợ ALL SEQUENCES trong publication, báo cáo lỗi đồng bộ sequence và cải thiện hành vi làm mới subscription liên quan đến sequence
  • Có thể dùng mệnh đề EXCEPT khi publication đăng tất cả bảng nhưng muốn loại trừ một số bảng
  • wal_level = replica tự động bật replication logic khi cần; effective_wal_level mới báo cáo hành vi thực tế, giúp giảm lỗi cấu hình và tăng khả năng quan sát

Autovacuum thông minh hơn và dễ quan sát hơn

  • Autovacuum có thể sử dụng vacuum worker song song, có thể kiểm soát ở cấp toàn cục và cấp bảng
    • Ví dụ cấu hình toàn cục: ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
  • Hệ thống điểm mới để kiểm soát thứ tự các bảng được vacuum, cải thiện việc đánh giá ưu tiên xem bảng nào khẩn cấp nhất
    • Ví dụ điều chỉnh trọng số theo bảng: mức khẩn cấp vacuum dựa trên insert là 3.0, mức khẩn cấp vacuum update/delete thông thường là 0.5
  • View pg_stat_autovacuum_scores mới cung cấp khả năng quan sát quá trình ra quyết định
    • Thông tin chi tiết trong các view tiến trình vacuum/analyze, mức dùng bộ nhớ và song song hóa trong VACUUM VERBOSE và log autovacuum, cùng log_autoanalyze_min_duration riêng giúp tăng khả năng quan sát bảo trì

Bổ sung truy vấn đồ thị thuộc tính SQL

  • Thêm SQL/PGQ (SQL property graph queries)
    • Các workload nơi mô hình đỉnh/cạnh hữu ích gồm phát hiện gian lận, gợi ý, phân tích mạng, đồ thị quyền, chuỗi cung ứng, sơ đồ tổ chức, v.v.
    • Ví dụ định nghĩa đồ thị thuộc tính: chỉ định VERTEX TABLES và EDGE TABLES bằng CREATE PROPERTY GRAPH store_graph
  • Cách tiếp cận là bổ sung một phương thức khác để truy vấn dữ liệu đã có, không từ bỏ mô hình quan hệ
    • Cùng hướng đi như JSONB, tìm kiếm toàn văn và extension trước đây, vốn không ép thay đổi kiến trúc hiện có
  • Từ góc nhìn lập trình viên, có thể dùng truy vấn dạng đồ thị mà không tăng thêm datastore riêng, đường đồng bộ, bề mặt vận hành hay đối tượng phải debug lúc 2 giờ sáng

COPY hữu dụng hơn

  • COPY FROM hỗ trợ bỏ qua nhiều dòng header
    • Hữu ích khi xử lý CSV export từ vendor, công cụ nội bộ hoặc file có thêm các dòng metadata ở đầu
  • COPY FROM thêm ON_ERROR SET_NULL để đặt giá trị nhập sai thành null, cung cấp lựa chọn giữa “toàn bộ load thất bại” và “làm sạch trước”
    • Có ví dụ load file trong đó cột price lẫn các giá trị 'N/A' và 'MISSING'
  • COPY TO có thể xuất định dạng JSON, bao gồm một mảng JSON duy nhất; cũng có thể xuất trực tiếp bảng partition (trước đây cần COPY (SELECT ...))
    • Ví dụ xuất bảng thành một mảng JSON hợp lệ: WITH (FORMAT JSON, ARRAY true)

Cải thiện tiện ích SQL

  • GROUP BY ALL tự động nhóm các biểu thức trong danh sách đích không phải aggregate và không phải window, giúp viết SQL thăm dò và truy vấn reporting gọn hơn
  • Hỗ trợ IGNORE NULLS và RESPECT NULLS cho window function được bổ sung vào lead, lag, first_value, last_value, nth_value
  • Thêm INSERT ... ON CONFLICT DO SELECT ... RETURNING để trả về trực tiếp hơn hàng bị xung đột trong upsert
  • Thêm UPDATE và DELETE FOR PORTION OF để tiếp tục hỗ trợ tác vụ liên quan đến thời gian (temporal), bao gồm các hàm thời gian RANDOM() mở rộng

Cải thiện hiệu năng trên diện rộng

  • Planner và executor có nhiều cải tiến về anti-join, semi-join, constant folding, incremental sort cho append path, xử lý aggregate trước join, tính độ chọn lọc của join, thống kê hàm, v.v.
  • Postgres tiến hóa theo hướng nhận diện tốt hơn các dạng truy vấn phổ biến và giảm công việc không cần thiết
    • Một số xử lý aggregate được thực hiện trước join, giảm số hàng cần xử lý
    • Nhiều trường hợp NOT IN và LEFT JOIN hơn được chuyển thành anti-join hiệu quả
    • Khả năng quan sát Memoize trong EXPLAIN được cải thiện, radix sort cải thiện hiệu năng sắp xếp, kiểm tra ràng buộc khóa ngoại nhanh hơn, và SIMD được dùng cho đầu vào text/CSV của COPY FROM
  • Trong nhiều trường hợp, chỉ cần upgrade là có hành vi tốt hơn mà không cần thay đổi mã ứng dụng

Vì sao Postgres 19 quan trọng

  • Điểm nổi bật không phải một tính năng đơn lẻ mà là độ bao phủ rộng (breadth)
    • Cho lập trình viên ứng dụng: truy vấn đồ thị, cú pháp SQL được cải thiện, window function tốt hơn, hành vi upsert tốt hơn
    • Cho người vận hành: REPACK CONCURRENTLY, autovacuum được cải thiện, monitoring tốt hơn, thay đổi checksum online, khả năng quan sát replication rộng hơn
    • Cho người dùng chú trọng hiệu năng: cải tiến planner, cải tiến SIMD, khả năng quan sát I/O bất đồng bộ, kiểm tra khóa ngoại nhanh, sắp xếp tốt hơn
    • Cho người xây dựng trên Postgres: hook mới, module tư vấn planner, cải tiến extension, truy xuất thống kê FDW, tiếp tục đầu tư vào hệ sinh thái extension
  • Postgres đang tiến hóa đồng thời không chỉ cho một workload hay một persona, mà như một cơ sở dữ liệu và nền tảng cho ứng dụng, vận hành, phân tích và mở rộng
  • Vì chưa phải GA, đây là lúc để thử nghiệm — chạy ứng dụng, kiểm tra migration, rà soát extension, kiểm tra plan của các truy vấn chính, kiểm tra replication logic và workflow bảo trì

Bài viết liên quan

1 bình luận

 
GN⁺ 3 giờ trước
Các ý kiến trên Hacker News

  • Tôi đã dùng Postgres, Oracle, MS SQL Server, MySQL trong các dự án thực tế; SQLite thì chưa dùng sâu nhưng biết đây là một lựa chọn tuyệt vời
    Dạo này, vì lợi ích của chính mình, tôi luôn tránh Oracle và MySQL/MariaDB
    Postgres rất tuyệt, nhưng tôi ước nó có kết nối nhẹ hơn và materialized view được cập nhật đồng bộ. Dù connection pooler có cải thiện tình hình, mức dùng bộ nhớ cho mỗi kết nối đồng thời vẫn lớn một cách bất thường; và những tính năng như indexed view của SQL Server cho phép triển khai các tình huống dữ liệu phức tạp một cách thanh nhã, đơn giản và luôn đúng
    SQL Server có thể đắt, nhưng trong nhiều trường hợp đáng đồng tiền, và nếu chọn kho dữ liệu cẩn thận thì có thể giảm rất nhiều rắc rối trong tương lai

    • Với các bài toán lưu trữ quan hệ, tôi chủ yếu dùng SQLite và MSSQL
      Nếu dùng nhà cung cấp miễn phí thì khó có gì vượt được SQLite, và hiện nó đáp ứng được phần lớn use case. Tuy vậy, nó bắt đầu hụt hơi ở mảng sao lưu, sao chép và công cụ. Nếu phải chịu trách nhiệm về tính sẵn sàng của hệ thống và khôi phục sau thảm họa, tôi không ngại chi tiền để giảm rủi ro
      Nếu đã định trả dù chỉ một ít tiền, tôi sẽ đi đến cùng. Trải nghiệm lập trình viên quanh MSSQL là vô song; SSMS và SQL project của Visual Studio, theo tôi, tốt hơn nhiều so với các kiểu Entity Framework hiện nay. Cộng thêm công cụ bên thứ ba như RedGate thì có thể thay thế cả những gói tư vấn trị giá hàng triệu đô
      Tôi sẽ không đề xuất dựng máy chủ Oracle hay DB2 mới, nhưng nếu đã có sẵn thì có lẽ tôi sẽ phản đối đến cùng việc refactor để loại bỏ chúng. Những cơ sở dữ liệu như vậy thường đi kèm vô số “chuyện kinh dị”, và nếu không còn lựa chọn nào khác mà phải tái hiện các tác dụng phụ kỳ quặc đó trên engine mới, bản thân doanh nghiệp có thể bị phá hỏng
    • Oracle là sự kết hợp của đau đớn, khổ sở, chi phí cao, kiện tụng và nỗi khốn cùng của con người. Nếu không có các quản lý cấp trung không chuyên kỹ thuật thích những đặc quyền kiểu tiệc tùng khi mua phần mềm đắt tiền, có lẽ nó đã sụp từ lâu
    • Ngay cả Microsoft dường như cũng gần như đã bỏ rơi SQL Server và dành nhiều thời gian hơn để cải thiện các sản phẩm Postgres khác nhau trên Azure. Phiên bản lớn gần nhất sau 2022 chỉ bổ sung thêm vài tính năng AI
      Với tư cách DBA, nếu đã làm nhiều tác vụ DBA nặng, Postgres ở một đẳng cấp khác so với SQL Server. Postgres native trên Linux và là mã nguồn mở, nên độ linh hoạt, khả năng quan sát nội bộ và khả năng vận hành không thể so với SQL Server
      Trong bối cảnh công nghệ hiện nay, tôi xem SQL Server về cơ bản đã chết. Các công ty dùng nó chỉ là những tổ chức legacy xoay quanh Windows, và ngay cả những nơi đó cũng đang ít dần
    • Tôi thật sự mong có materialized view cập nhật đồng bộ. Theo thuật ngữ Oracle thì có vẻ là kiểu “refresh on commit”
      Sẽ tốt hơn nữa nếu có cả tùy chọn cập nhật trì hoãn. Đó là cách gom nhiều update lại xử lý một lần, chỉ xét các bản ghi đã thay đổi kể từ lần refresh cuối; tôi không rõ Oracle làm việc này về mặt kỹ thuật như thế nào. Tính năng này có lẽ sẽ là một bổ sung tuyệt vời so với gần như mọi cơ sở dữ liệu OLTP mã nguồn mở
      Tôi cũng rất tò mò về dự án OrioleDB: https://github.com/orioledb/orioledb/releases
      Vài năm trước, tôi đã khá khổ sở vì vacuum khi có rất nhiều thao tác chèn/xóa ngẫu nhiên liên tục trên một nơi giống bảng tạm. Tôi giải quyết bằng cách gom thêm thay đổi trong RAM rồi flush xuống bảng để tăng số hàng thay đổi trên mỗi page, nhưng đã rất vất vả để tìm được điểm cân bằng tốt
    • PostgreSQL là sản phẩm tốt hơn, nhưng không có khả năng mở rộng ngang của MySQL/MariaDB. Vì vậy nếu cần một cluster dễ cấu hình, chẳng hạn một cửa hàng bán lẻ trực tuyến quy mô lớn, MySQL vẫn hữu dụng

  • Với tư cách người đã dùng Postgres hơn 15 năm trong lĩnh vực khoa học, tôi bắt đầu lo ngại việc PostgreSQL không có lưu trữ hướng cột
    Khi dataset ngày càng lớn, giới hạn của storage trong PG càng trở nên rõ hơn. Nhiều extension như cetus có thể cung cấp tính năng này, nhưng như vậy sẽ phải phụ thuộc vào việc extension đó có tiếp tục được hỗ trợ hay không, đồng thời độ phức tạp cũng tăng lên

    • Hơi tự quảng bá một chút, nhưng tôi đã làm vấn đề này dưới dạng extension trong vài tháng qua: https://github.com/xataio/deltax
      Ban đầu tôi nghĩ nếu dùng bảng Postgres làm storage và dùng executor của Postgres thì overhead cố hữu sẽ quá lớn; nếu đạt được hiệu năng ngang Timescale thì đã khá tuyệt. Tôi không nghĩ nó có thể tiến gần tới một cơ sở dữ liệu phân tích chuyên dụng
      Nhưng khi dự án tiến triển, hiệu năng tiếp tục được cải thiện, và giờ tôi chắc chắn ủng hộ hướng làm workload phân tích bằng Postgres + extension
    • Nếu kỳ vọng điều đó, có thể bạn đã chọn sai cơ sở dữ liệu. Cơ sở dữ liệu hướng cột là một phạm trù riêng
      Nó giống như lo rằng Apple không bán máy giặt vậy
    • Từ góc nhìn khoa học máy tính, tôi không rõ cơ sở dữ liệu giao dịch sẽ triển khai dạng cột như thế nào. Khi quy mô lớn lên, tổ hợp như Postgres + CDC + ClickHouse, tức kết hợp với một cơ sở dữ liệu phân tích thực thụ, có lẽ là lựa chọn mạnh nhất
    • Nếu dataset ngày càng lớn, có vẻ tốt hơn là giữ dữ liệu mới trong PostgreSQL và định kỳ archive dữ liệu cũ sang một cơ sở dữ liệu kiểu data warehouse, để Postgres luôn gọn nhẹ
      Ngày nay, nhiều công ty dùng thêm cơ sở dữ liệu key-value hoặc document store song song với cơ sở dữ liệu quan hệ trong ứng dụng chính
    • Với tư cách người dùng 25 năm, tôi thấy trạng thái hiện tại cũng ổn. Nhiều hơn không nhất thiết tốt hơn; cứ nhìn Redis là thấy

  • Tôi không hiểu vì sao lại không nhắc đến việc PostgreSQL 19 đưa vào hỗ trợ dữ liệu thời gian application-time native dựa trên chuẩn SQL:2011: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

    • Thật ngạc nhiên là bài gốc không đề cập đến điều này. Trước đây, người ta triển khai bằng cách tự thêm trigger tcn và các bảng bóng _archive: https://www.postgresql.org/docs/current/tcn.html
      Nếu tính năng này trở thành native thì, như phần lớn các triển khai của PostgreSQL, nó sẽ thực sự tuyệt vời
    • Query Hints cũng chỉ được nhắc lướt qua nên hơi tiếc. Đã có một cuộc thảo luận thú vị bên dưới một bài trước đó có tiêu đề tương tự
      https://news.ycombinator.com/item?id=48413655
    • Đây là tính năng hay, nhưng thành thật mà nói tôi nghĩ dùng cho tốt sẽ hơi khó. Và cần cẩn thận để PII không còn nằm đâu đó trong khoảng hư vô temporal quá lâu

  • Tôi không phân biệt được liệu bài này dùng văn phong bị lấy mẫu quá nhiều trong dữ liệu huấn luyện LLM, hay đã dùng AI khá nhiều để chỉnh sửa bài viết. Tôi nghiêng về khả năng sau

    • Gọi là “chỉnh sửa” thì quá rộng lượng. Điều khiến tôi khó chịu hơn là thông tin tác giả gây hiểu lầm. Không tìm thấy craig-kerstiens trên Hugging Face, và trong bài này không có câu nào trông như được gõ trực tiếp bằng bàn phím
      Tôi cho rằng việc Claude viết những câu kiểu “với tư cách là người đã làm X trong nhiều năm” là một dạng lỗi alignment. LLM không nên viết như thể nó có trải nghiệm cá nhân. Dữ liệu huấn luyện có thể có người nói theo cách đó, nhưng dù là một chuỗi token có vẻ hợp lý về mặt thống kê, tôi nghĩ LLM không nên tuyên bố có những trải nghiệm sống mà nó không có
    • Không cần phải nhìn nhận rộng lượng. Snowflake đã sa thải các technical writer với lý do sẽ thay thế bằng AI: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
    • Kiểu bình luận ít nỗ lực chỉ trích văn phong/định dạng như thế này đi ngược lại hướng dẫn thảo luận của Hacker News, và cần có biện pháp dọn dẹp phần bình luận. Giờ nó đã trở nên nực cười rồi
    • Pangram đánh giá toàn bộ văn bản này là do AI tạo, nhưng tôi không biết có thể tin Pangram đến mức nào. Tôi cũng muốn nghe suy nghĩ của người khác
    • Tôi hiểu là đoán xem có dùng AI hay không đang là mốt. Nhưng nếu có điểm để phê bình, tôi nghĩ phê bình sản phẩm cuối cùng sẽ hữu ích hơn

  • Tôi thích các cải tiến về COPY và logical replication. Hiện tại tôi đang sao lưu cơ sở dữ liệu PG sang một instance Databasus sidecar, mà nó còn nặng hơn cả toàn bộ backend + DB + Caddy
    Dưới đây là lời phàn nàn về văn phong LLM
    Nếu phải đọc những câu như “Chỉ riêng điều đó cũng cho thấy: người dùng có nhu cầu thực sự, và hệ sinh thái đã lấp khoảng trống đó”, “Nó trông đơn giản nhưng giải quyết các vấn đề vận hành thực tế”, “Nó không thay đổi thế giới, nhưng khiến các workflow dữ liệu hằng ngày tốt hơn”, có lẽ nếu Orwell còn sống đến giờ, ông đã tuyên bố mù chữ tiếng Anh và đi học tiếng Klingon

  • Tính năng cơ sở dữ liệu đồ thị trông có vẻ thú vị, nhưng cú pháp GRAPH_TABLE thì quá khủng khiếp
    SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
    Nó làm tôi nhớ đến neo4j, nhưng tôi không nghĩ đó là thứ mà một công cụ nghiêm túc vào năm 2026 nên sao chép nguyên xi
    Rốt cuộc điều tôi tò mò là tốc độ. row-level security là một tính năng rất hữu ích, nhưng cố xây thứ gì đó nghiêm túc bằng triển khai của Postgres là liều lĩnh. Vì planner sẽ rối tung và nó match từng hàng, phá hỏng hiệu năng

    • Đó không phải là một cú pháp tùy tiện do Postgres tự nghĩ ra
      Nó là SQL/PGQ, bắt nguồn từ ngôn ngữ Cypher của Neo4J và giờ đã là một phần của chuẩn SQL
    • Bạn nói planner kiểm tra từng hàng trong row-level security ư? Đó chính là Row-level security. Nếu không thì còn cách nào khác để xác minh một hàng có vượt qua policy hay không?

  • Tôi mong PostgreSQL có thêm nén khối chứ không chỉ nén hàng. Chỉ nén hàng thì hiệu quả quá hạn chế
    Có thể đặt dữ liệu trên ZFS pool và bật nén khối, nhưng nếu được hỗ trợ native thì sẽ giảm gánh nặng cấu hình và có thể hiệu năng cũng tốt hơn

  • GROUP BY ALL nghĩ kỹ thì thật sự rất hợp lý, nhưng trước đây tôi chưa từng nghĩ đến nên thấy khá thú vị

  • Từ góc nhìn gần với DevOps, tôi mong PostgreSQL cuối cùng cũng hỗ trợ nâng cấp tại chỗ giữa các major version liên tiếp
    Phần lớn các bản phân phối có thể xử lý đặc tính phiền phức là phải chạy cả phiên bản cũ lẫn mới cho pg_upgrade, nhưng nếu dùng Docker thì việc nâng cấp lên major version mới thật sự rất đau đớn

  • Thật vui khi GROUP BY ALL được đưa vào. Theo tôi biết thì đây là khái niệm do DuckDB giới thiệu
    Tài liệu DuckDB cũng nói rằng nhiều tính năng được DuckDB giới thiệu đầu tiên, và các tính năng như GROUP BY ALL sau đó đã được các hệ thống khác áp dụng
    https://duckdb.org/docs/lts/sql/dialect/friendly_sql