CHỌN có loại bỏ các hàng chết như VACUUM không?


9

Tôi đã loay hoay VACUUMvà nhận thấy một số hành vi bất ngờ trong đó SELECTcác hàng ing từ một bảng dường như làm giảm công việc VACUUMphải làm sau đó.

Kiểm tra dữ liệu

Lưu ý: autovacuum bị vô hiệu hóa

CREATE TABLE numbers (num bigint);
ALTER TABLE numbers SET (
  autovacuum_enabled = 'f',
  toast.autovacuum_enabled = 'f'
);

INSERT INTO numbers SELECT generate_series(1, 5000);

Thử nghiệm 1

Bây giờ chúng tôi chạy một bản cập nhật trên tất cả các hàng,

UPDATE numbers SET num = 0;

Và khi chúng tôi chạy, VACUUM (VERBOSE) numbers;chúng tôi nhận được,

INFO:  vacuuming "public.numbers"
INFO:  "numbers": removed 5000 row versions in 23 pages
INFO:  "numbers": found 5000 removable, 5000 nonremovable row versions in 45 out of 45 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 6585
There were 0 unused item pointers.

Phiên tòa 2

Bây giờ chúng tôi phát hành một cái khác UPDATE, nhưng lần này chúng tôi thêm một lần SELECTsau,

UPDATE numbers SET num = 1;
SELECT * FROM numbers;

Và khi chúng tôi chạy, VACUUM (VERBOSE) numbers;chúng tôi nhận được,

INFO:  vacuuming "public.numbers"
INFO:  "numbers": removed 56 row versions in 22 pages
INFO:  "numbers": found 56 removable, 5000 nonremovable row versions in 45 out of 45 pages
DETAIL:  0 dead row versions cannot be removed yet, oldest xmin: 6586
There were 56 unused item pointers.

Chính xác thì chuyện gì đang xảy ra ở đây? Tại sao phiên bản thứ hai tôi chạy, sau khi SELECTxóa bộ dữ liệu chết khỏi các trang mà nó truy cập, khá giống như VACUUMvậy?

Tôi đang chạy Postgres 11.3 trên macOS 10.14.5.


2
Khách hàng nào bạn sử dụng để chạy các lệnh của bạn? Là autocommit được kích hoạt trong đó?
mustaccio

2
Tôi sẽ xóa câu hỏi "Có phải bảng VACUUM về cơ bản chỉ là CHỌN * TỪ bảng dưới mui xe?" (không phải vậy) Tôi nghĩ rằng đó là một cách theo dõi tốt, câu trả lời ở đây chỉ đơn giản là CHỌN có thể loại bỏ các hàng chết và nó có chung điểm chung với VACUUM. Làm thế nào chúng khác nhau sẽ là một cuộc trò chuyện rất căng thẳng về tái đầu tư XID và rất nhiều thứ khác. Câu hỏi đó về cơ bản là "Những thứ khác làm chân không làm gì ngoài việc loại bỏ các hàng chết". (Điều này sẽ là mơ hồ)
Evan Carroll

@mustaccio Tôi đã thực hiện các thử nghiệm này với tập lệnh Ruby bằng ActiveRecord, sử dụng đá quý PG dưới mui xe. Tôi tin rằng autocommit được bật theo mặc định vì bạn không cần phải đưa ra bất kỳ CAM KẾT nào trừ khi BEGIN được sử dụng rõ ràng.
rafbm

Câu trả lời:


5

Từ bài đăng này trên / r / PostgreSQL đến câu trả lời của Laurenz Albe , có vẻ như các bản cập nhật Heap Only Tuples (HOT) có thể chịu trách nhiệm. Từ mô tả các cập nhật HOT trongsrc/backend/access/heap/README.HOT

Thực tế, việc cải tạo không gian xảy ra trong quá trình truy xuất tuple khi trang gần đầy (<10% miễn phí) và có thể lấy được khóa dọn dẹp bộ đệm. Điều này có nghĩa rằng UPDATE, DELETESELECTcó thể gây ra không gian cải tạo, nhưng thường không trong suốt INSERT ... VALUESvì nó không lấy một hàng.

Câu trích dẫn không có trong câu trả lời ban đầu, nhưng phần còn lại là một câu trích dẫn,

Để hỗ trợ hoặc bác bỏ lý thuyết này, hãy chạy truy vấn sau:

SELECT n_tup_upd, n_tup_hot_upd
FROM pg_stat_user_tables
WHERE schemaname = 'public' AND relname = 'TABLE_NAME';

Nếu n_tup_hot_updlớn hơn 0, chúng ta đã có một trường hợp.


Bây giờ chúng ta nói chuyện. +1
mustaccio

NÓNG dường như là một lời giải thích tốt. Nếu I CREATE INDEX idx_numbers ON numbers USING btree (num), đầu ra VACUUM thay đổi thành INFO: "numbers": removed 5000 row versions in 45 pages. Tuy nhiên, lưu ý rằng trong kịch bản không có chỉ mục, n_tup_hot_updluôn là 0, cả giữa CẬP NHẬT và CHỌN và giữa CHỌN và VACUUM. Tôi cũng đảm bảo chạy SELECT pg_sleep(10)giữa mỗi câu lệnh để thống kê được cập nhật (tôi thấy seq_scan: 2, một cho CẬP NHẬT và một cho CHỌN).
rafbm

Có phải chọn tạo WAL trong trường hợp này? Tôi có ấn tượng rằng lựa chọn không tạo ra WAL. Nếu có, điều này có nghĩa là việc loại bỏ các hàng chết được truyền đến bất kỳ nô lệ nào. Nếu không, điều này có nghĩa là việc hút bụi vẫn là cần thiết trên nô lệ. Điều đó cũng có nghĩa là chủ và nô lệ không giống nhau chút nào. Hmm, có lẽ tôi cần thực hiện một số nghiên cứu và gửi một câu hỏi và / hoặc câu trả lời hoặc hai.
Colin 't Hart

1

Trong trường hợp đặc biệt của một bảng không liên kết, có, CHỌN có thể thực hiện công việc tương tự như VACUUM (liên quan đến việc loại bỏ các hàng chết).


3
Bạn có thể thêm một lời giải thích?
Laurenz Albe
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.