Sửa đổi thành GEQO (Tối ưu hóa truy vấn di truyền) của PostgreSQL


16

Tôi cần triển khai một chức năng phù hợp với chức năng GEQO của PostgreSQL. Tôi hiểu rằng cách tiếp cận GEQO là mã hóa các kế hoạch truy vấn dưới dạng các chuỗi số nguyên và GEQO tạo ra các chuỗi tham gia có thể này một cách ngẫu nhiên. Nguồn: http://www.postgresql.org/docs/9.3/static/geqo-pg-intro.html

Câu hỏi của tôi: làm thế nào để sửa đổi hàm GEQO nếu tôi chắc chắn biết trình tự tham gia đúng, để tôi không phải tìm kiếm các chuỗi tham gia khác nhau. Ví dụ, nếu tôi biết rằng cách tốt nhất để tham gia 4 mối quan hệ là 4-1-3-2, tôi không cần phải kiểm tra các hoán vị khác.

Không có bất kỳ tài liệu tốt nào về cách GEQO được triển khai trong PostgreSQL. PostgreSQL chỉ cung cấp cái nhìn tổng thể về chức năng GEQO nhưng không giải thích nhiều.

Hoặc tôi có thể đạt được chức năng này trong tiêu chuẩn_join_search () mà không cần sử dụng GEQO không?


3
Có vẻ như bạn muốn thực hiện gợi ý truy vấn. Đó là tất cả tốt và tốt, nhưng bạn không nên mong đợi sự thay đổi được chấp nhận trong lõi PostgreSQL vì cộng đồng dự án không phải là thứ bạn gọi là một fan hâm mộ lớn của các gợi ý truy vấn. Nếu bạn nghiêm túc về vấn đề này, bạn sẽ cần đọc khá nhiều mã kế hoạch truy vấn và bạn sẽ cần tìm ra cách chuyển gợi ý của mình từ trình phân tích cú pháp thông qua trình viết lại và vào trình lập kế hoạch. Tôi không thấy một câu trả lời nhanh chóng và đơn giản ở đây. Những gì bạn muốn cuối cùng làm là buộc một lựa chọn đường dẫn cụ thể trong trình lập kế hoạch / tối ưu hóa.
Craig Ringer

Ah, vâng, họ hoài nghi về gợi ý truy vấn. Tôi đã đọc xong mã kế hoạch và dường như GEQO sẽ là một cách để giảm thiểu các thay đổi đối với lõi hiện có.
dùng2761431

2
Đó có phải là những gì bạn đang cố gắng để đạt được, để thực hiện các gợi ý truy vấn để buộc tham gia đặt hàng? Nếu vậy, hãy xem liệu có ai khác đã thực hiện nó chưa. Bạn cũng nên xem xét lý do tại sao bạn cần nó, tại sao người lập kế hoạch lại đưa ra những lựa chọn sai lầm ngay từ đầu. Xem xét việc sản xuất một trường hợp thử nghiệm độc lập và báo cáo cho hiệu suất pssql.
Craig Ringer

3
pg_hint_plan : en.sourceforge.jp/projects/pghintplan , nhưng tôi đã không sử dụng nó. Một dba nói với tôi rằng nó đang hoạt động vào ngày 9.2. Ngoài ra còn có bài viết bằng tiếng Nga về nó habrahabr.ru/post/169751
ckorzhik

Câu trả lời:


1

Một cách bạn có thể làm điều này mà không cần phải loay hoay với GEKO là sử dụng CTE.

CTE là các rào cản tối ưu hóa, do đó bạn có thể bọc các liên kết bên trong CTE theo thứ tự bạn muốn và PG sẽ buộc phải làm như vậy.

Ví dụ: nếu chúng ta muốn buộc DB tham gia t1 đầu tiên với t2 và chỉ sau đó với t4, chúng ta mới có thể chạy một cái gì đó như:

explain 
with j1 as (select *,t1.c4 as t1c4 from t1 join t2 on (t1.c2=t2.id))
    ,j2 as (select * from j1 join t4 on (t1c4=t4.id))
select * from j2;

Điều này sẽ dẫn đến:

                                  QUERY PLAN                                   
-------------------------------------------------------------------------------
CTE Scan on j2  (cost=51485.00..67785.00 rows=815000 width=64)
CTE j1
 ->  Hash Join  (cost=3473.00..14521.00 rows=815000 width=40)
       Hash Cond: (t2.id = t1.c2)
       ->  Seq Scan on t2  (cost=0.00..26.30 rows=1630 width=20)
       ->  Hash  (cost=1637.00..1637.00 rows=100000 width=20)
             ->  Seq Scan on t1  (cost=0.00..1637.00 rows=100000 width=20)
CTE j2
 ->  Hash Join  (cost=289.00..36964.00 rows=815000 width=64)
       Hash Cond: (j1.t1c4 = t4.id)
       ->  CTE Scan on j1  (cost=0.00..16300.00 rows=815000 width=44)
       ->  Hash  (cost=164.00..164.00 rows=10000 width=20)
             ->  Seq Scan on t4  (cost=0.00..164.00 rows=10000 width=20)
(13 rows)

Đây chỉ là một ví dụ, bạn có thể thay đổi nó khi cần - trong mọi trường hợp PG không thể thay đổi thứ tự giữa các CTE khác nhau.

Hy vọng nó giúp :)

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.