Erwin, vì đây là cuộc thảo luận của chúng tôi trong chuỗi nhận xét từ trước, tôi quyết định chọc vào nó thêm một chút ...
Tôi có một truy vấn rất đơn giản từ một bảng có kích thước hợp lý. Tôi thường có đủ work_mem
, nhưng trong trường hợp này tôi đã sử dụng các lệnh
SET work_mem = 64;
để đặt rất nhỏ work_mem
và
SET work_mem = default;
để đặt work_mem
lưng của tôi đủ lớn cho truy vấn của tôi.
GIẢI THÍCH & Kiểm tra lại điều kiện
Vì vậy, chạy truy vấn của tôi chỉ EXPLAIN
với
EXPLAIN
SELECT * FROM olap.reading_facts
WHERE meter < 20;
Tôi đã thu được kết quả cho cả thấp và cao work_mem
:
Thấp work_mem
Bitmap Heap Scan on reading_facts (cost=898.92..85632.60 rows=47804 width=32)
Recheck Cond: (meter < 20)
-> Bitmap Index Scan on idx_meter_reading_facts (cost=0.00..886.96 rows=47804 width=0)
Index Cond: (meter < 20)
Cao work_mem
Bitmap Heap Scan on reading_facts (cost=898.92..85632.60 rows=47804 width=32)
Recheck Cond: (meter < 20)
-> Bitmap Index Scan on idx_meter_reading_facts (cost=0.00..886.96 rows=47804 width=0)
Index Cond: (meter < 20)
Câu chuyện dài, cho EXPLAIN
chỉ, như dự kiến, kế hoạch truy vấn chỉ ra rằng điều kiện Kiểm tra lại là có thể, nhưng chúng ta không thể biết liệu thực sự sẽ được tính toán hay không.
GIẢI THÍCH ANALYZE & Kiểm tra lại điều kiện
Khi chúng tôi đưa ANALYZE
vào truy vấn, kết quả sẽ cho chúng tôi biết thêm về những gì chúng tôi cần biết.
Thấp work_mem
Bitmap Heap Scan on reading_facts (cost=898.92..85632.60 rows=47804 width=32) (actual time=3.130..13.946 rows=51840 loops=1)
Recheck Cond: (meter < 20)
Rows Removed by Index Recheck: 86727
Heap Blocks: exact=598 lossy=836
-> Bitmap Index Scan on idx_meter_reading_facts (cost=0.00..886.96 rows=47804 width=0) (actual time=3.066..3.066 rows=51840 loops=1)
Index Cond: (meter < 20)
Cao work_mem
Bitmap Heap Scan on reading_facts (cost=898.92..85632.60 rows=47804 width=32) (actual time=2.647..7.247 rows=51840 loops=1)
Recheck Cond: (meter < 20)
Heap Blocks: exact=1434
-> Bitmap Index Scan on idx_meter_reading_facts (cost=0.00..886.96 rows=47804 width=0) (actual time=2.496..2.496 rows=51840 loops=1)
Index Cond: (meter < 20)
Một lần nữa, như mong đợi, việc đưa vào ANALYZE
tiết lộ cho chúng tôi một số thông tin rất quan trọng. Trong work_mem
trường hợp thấp , chúng tôi thấy rằng có các hàng bị xóa bởi kiểm tra lại chỉ mục và chúng tôi có lossy
các khối heap.
Phần kết luận? (hoạc thiếu điều đó)
Thật không may, có vẻ như EXPLAIN
bản thân nó không đủ để biết liệu kiểm tra lại chỉ số có thực sự cần thiết hay không bởi vì một số id của hàng bị bỏ qua để giữ lại các trang trong quá trình quét heap bitmap.
Sử dụng EXPLAIN ANALYZE
là tốt để chẩn đoán các vấn đề với các truy vấn có độ dài vừa phải, nhưng trong trường hợp truy vấn mất một thời gian rất dài để hoàn thành, sau đó chạy EXPLAIN ANALYZE
để phát hiện ra rằng chỉ số bitmap của bạn đang chuyển thành mất do không đủ work_mem
vẫn là một ràng buộc khó khăn. Tôi ước có một cách để EXPLAIN
ước tính khả năng xảy ra sự cố này từ bảng thống kê.