Chỉ mục không được sử dụng, nhưng ảnh hưởng đến truy vấn

Tôi đã có một bảng PostgreSQL 9.3 với một số số và một số dữ liệu bổ sung:

CREATE TABLE mytable (
    myid BIGINT,
    somedata BYTEA
)

Bảng này hiện có khoảng 10 triệu bản ghi và chiếm 1GB dung lượng đĩa. myidkhông liên tiếp.

Tôi muốn tính toán có bao nhiêu hàng trong mỗi khối 100000 số liên tiếp:

SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;

Điều này trả về khoảng 3500 hàng.

Tôi nhận thấy rằng sự tồn tại của một chỉ mục nhất định tăng tốc đáng kể truy vấn này mặc dù kế hoạch truy vấn hoàn toàn không đề cập đến nó. Kế hoạch truy vấn không có chỉ mục:

db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=1636639.92..1709958.65 rows=496942 width=8) (actual time=6783.763..8888.841 rows=3460 loops=1)
   Output: ((myid / 100000)), count(*)
   ->  Sort  (cost=1636639.92..1659008.91 rows=8947594 width=8) (actual time=6783.752..8005.831 rows=8947557 loops=1)
         Output: ((myid / 100000))
         Sort Key: ((mytable.myid / 100000))
         Sort Method: external merge  Disk: 157440kB
         ->  Seq Scan on public.mytable  (cost=0.00..236506.92 rows=8947594 width=8) (actual time=0.020..1674.838 rows=8947557 loops=1)
               Output: (myid / 100000)
 Total runtime: 8914.780 ms
(9 rows)

Chỉ số:

db=> CREATE INDEX myindex ON mytable ((myid/100000));
db=> VACUUM ANALYZE;

Gói truy vấn mới:

db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;
                                                            QUERY PLAN                                                            
----------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=281242.99..281285.97 rows=3439 width=8) (actual time=3190.189..3190.800 rows=3460 loops=1)
   Output: ((myid / 100000)), count(*)
   ->  Seq Scan on public.mytable  (cost=0.00..236505.56 rows=8947485 width=8) (actual time=0.026..1659.571 rows=8947557 loops=1)
         Output: (myid / 100000)
 Total runtime: 3190.975 ms
(5 rows)

Vì vậy, các kế hoạch truy vấn và thời gian chạy khác nhau đáng kể (gần ba lần) nhưng không đề cập đến chỉ số. Hành vi này có thể tái tạo hoàn hảo trên máy dev của tôi: Tôi đã trải qua nhiều chu kỳ bỏ chỉ mục, kiểm tra truy vấn nhiều lần, tạo lại chỉ mục, một lần nữa kiểm tra truy vấn nhiều lần. Chuyện gì đang xảy ra ở đây vậy?

VACUUM ANALYZElàm cho sự khác biệt trong ví dụ của bạn Ngoài ra, như @jjanes đã cung cấp , số liệu thống kê bổ sung cho chỉ mục chức năng. Mỗi tài liệu:

pg_statisticcũng lưu trữ dữ liệu thống kê về các giá trị của biểu thức chỉ mục. Chúng được mô tả như thể chúng là các cột dữ liệu thực tế; đặc biệt, starelidtham khảo các chỉ số. Tuy nhiên, không có mục nào được tạo cho một cột chỉ mục không biểu thức thông thường, vì nó sẽ là dự phòng với mục nhập cho cột bảng bên dưới.

Tuy nhiên, việc tạo chỉ mục không tự nó khiến Postgres thu thập số liệu thống kê. Thử:

CREATE INDEX myindex ON mytable ((myid/100000));
SELECT * FROM pg_statistic WHERE starelid = 'myindex'::regclass;

Trả về không có gì cho đến khi bạn chạy lần đầu tiên ANALYZE(hoặc VACUUM ANALYZE, hoặc trình tự động tự động khởi động).

ANALYZE mytable;
SELECT * FROM pg_statistic WHERE starelid = 'myindex'::regclass;

Bây giờ bạn sẽ thấy số liệu thống kê được thêm vào.

Vì toàn bộ bảng phải được đọc bằng mọi cách, Postgres sẽ sử dụng quét tuần tự trừ khi dự kiến ​​tính toán của myid/100000nó đủ đắt để chuyển đổi, điều này không phải là.

Cơ hội duy nhất khác của bạn sẽ là quét chỉ mục nếu chỉ mục nhỏ hơn nhiều so với bảng - và điều kiện tiên quyết cho quét chỉ mục được đáp ứng. Chi tiết trong Wiki Postgres và trong hướng dẫn .

Miễn là chỉ số chức năng đó không được sử dụng, lợi ích tài sản thế chấp từ số liệu thống kê được thêm vào là vừa phải. Nếu bảng chỉ đọc, chi phí sẽ thấp - nhưng một lần nữa, có lẽ chúng ta sẽ thấy quét chỉ mục ngay lập tức.

Có lẽ bạn cũng có thể đạt được các kế hoạch truy vấn tốt hơn bằng cách đặt mục tiêu thống kê cao hơn cho mytable.myid. Điều đó sẽ chỉ phát sinh một chi phí nhỏ. Hơn:

• PostgreSQL + công cụ lập kế hoạch truy vấn + số lượng thực thể

Khi bạn tạo một chỉ mục biểu thức, nó khiến PostgreSQL thu thập số liệu thống kê về biểu thức đó. Với các số liệu thống kê trên tay, giờ đây nó có một ước tính chính xác cho số lượng hàng tổng hợp mà truy vấn sẽ trả về, điều này dẫn đến việc đưa ra lựa chọn kế hoạch tốt hơn.

Cụ thể trong trường hợp này, nếu không có những thống kê bổ sung đó, nó nghĩ rằng bảng băm sẽ quá lớn để phù hợp với work_mem, vì vậy nó đã không chọn phương thức đó.