Do PostgreSQL MVCC, một UPDATE thực sự giống như một DELETE cộng với một INSERT . Với ngoại lệ đáng chú ý của các giá trị nướng - xem:
- Postgres có viết lại toàn bộ hàng khi cập nhật không?
(Và sự khác biệt nhỏ đối với các bộ chỉ heap - DELETE + INSERT bắt đầu một chuỗi HOT mới - nhưng điều đó không liên quan đến trường hợp hiện tại.)
Nói một cách chính xác, hàng "đã xóa" chỉ ẩn đối với bất kỳ giao dịch nào bắt đầu sau khi quá trình xóa đã được thực hiện và sẽ được hút sạch sau đó. Do đó, về phía cơ sở dữ liệu, bao gồm cả thao tác lập chỉ mục, có hiệu lực không có sự khác biệt giữa hai câu lệnh. (Áp dụng ngoại lệ, hãy tiếp tục đọc.) Nó làm tăng lưu lượng mạng một chút (tùy thuộc vào dữ liệu của bạn) và cần một chút phân tích cú pháp.
Tôi đã nghiên cứu thêm một số cập nhật HOT sau khi nhập @ araqnid và chạy một số bài kiểm tra. Cập nhật trên các cột không thực sự thay đổi giá trị không tạo ra sự khác biệt bất kỳ thông tin cập nhật HOT nào có liên quan. Câu trả lời của tôi là đúng. Xem chi tiết bên dưới.
Điều này cũng áp dụng cho các thuộc tính nướng, vì chúng cũng không được chạm vào trừ khi các giá trị thực sự thay đổi .
Tuy nhiên , nếu bạn sử dụng trình kích hoạt mỗi cột (được giới thiệu với pg 9.0), điều này có thể có tác dụng phụ không mong muốn!
Tôi trích dẫn hướng dẫn về trình kích hoạt:
... một lệnh chẳng hạn như
UPDATE ... SET x = x ...sẽ kích hoạt cột trên kích hoạtx, ngay cả khi giá trị của cột không thay đổi .
Nhấn mạnh đậm của tôi.
Các lớp trừu tượng là để thuận tiện. Chúng hữu ích cho các nhà phát triển không biết SQL hoặc nếu ứng dụng cần phải di động giữa các RDBMS khác nhau. Mặt khác, họ có thể làm thịt hiệu suất và giới thiệu các điểm thất bại bổ sung. Tôi tránh chúng bất cứ khi nào có thể.
Cập nhật HOT (bộ chỉ Heap)
Các Tuples chỉ dành cho Heap đã được giới thiệu với Postgres 8.3, với những cải tiến quan trọng trong 8.3.4 và 8.4.9.
Các ghi chú phát hành cho Postgres 8.3:
UPDATEs vàDELETEs để lại các bộ giá trị đã chết, cũng như không thành côngINSERTs. Chỉ trước đâyVACUUMcó thể lấy lại không gian bị chiếm bởi các bộ giá trị đã chết. WithHOT dead tuple space có thể được tự động lấy lại tại thời điểmINSERThoặcUPDATEnếu không có thay đổi nào được thực hiện đối với các cột được lập chỉ mục . Điều này cho phép hiệu suất ổn định hơn. Ngoài ra, HOT tránh thêm các mục nhập chỉ mục trùng lặp.
Nhấn mạnh của tôi. Và "không có thay đổi" bao gồm các trường hợp trong đó các cột được cập nhật với cùng giá trị như chúng đã được giữ. Tôi đã thực sự thử nghiệm , vì tôi không chắc.
Cuối cùng, README.HOT mở rộng trong mã nguồn xác nhận điều đó.
Các cột nướng cũng không cản trở các bản cập nhật HOT. Tuple được cập nhật HOT chỉ liên kết đến (các) tuple giống nhau, không thay đổi trong ngã ba bánh mì nướng của mối quan hệ. Cập nhật HOT thậm chí hoạt động với các giá trị được nướng trong danh sách mục tiêu (thực sự đã thay đổi hoặc không). Nếu các giá trị bánh mì nướng bị thay đổi, rõ ràng là nó sẽ dẫn đến việc ghi vào nhánh quan hệ bánh mì nướng. Tôi cũng đã thử nghiệm tất cả những điều đó.
Đừng lấy lời của tôi cho nó, hãy xem cho chính mình. Postgres cung cấp một số chức năng để kiểm tra số liệu thống kê. Chạy UPDATE của bạn có và không có tất cả các cột và kiểm tra xem nó có tạo ra sự khác biệt nào không.
-- Number of rows HOT-updated in table:
SELECT pg_stat_get_tuples_hot_updated('table_name'::regclass::oid)
-- Number of rows HOT-updated in table, in the current transaction:
SELECT pg_stat_get_xact_tuples_hot_updated('table_name'::regclass::oid)
Hoặc sử dụng pgAdmin. Chọn bảng của bạn và kiểm tra tab "Thống kê" trong cửa sổ chính.
Lưu ý rằng chỉ có thể cập nhật HOT khi có chỗ cho phiên bản tuple mới trên cùng một trang của ngã ba quan hệ chính. Một cách đơn giản để bắt buộc điều kiện đó là kiểm tra với một bảng nhỏ chỉ chứa một vài hàng. Kích thước trang thường là 8k, vì vậy phải có không gian trống trên trang.
