Modifikasi menjadi GEQO (Optimalisasi Kueri Genetik) dari PostgreSQL


16

Saya perlu mengimplementasikan fungsionalitas yang sejalan dengan fungsionalitas GEQO dari PostgreSQL. Saya mengerti bahwa pendekatan GEQO adalah untuk menyandikan rencana kueri sebagai string integer dan GEQO menghasilkan urutan gabungan yang mungkin ini secara acak. Sumber: http://www.postgresql.org/docs/9.3/static/geqo-pg-intro.html

Pertanyaan saya: bagaimana cara memodifikasi fungsi GEQO jika saya secara pasti mengetahui urutan bergabung yang benar, sehingga saya tidak perlu mencari urutan bergabung yang berbeda. Sebagai contoh, jika saya tahu bahwa cara terbaik untuk bergabung dengan 4 relasi adalah 4-1-3-2, saya tidak perlu memeriksa permutasi lainnya.

Tidak ada bahan yang bagus tentang bagaimana GEQO diimplementasikan di PostgreSQL. PostgreSQL hanya memberikan tampilan keseluruhan dari fungsi GEQO tetapi tidak banyak menjelaskan.

Atau bisakah saya mencapai fungsionalitas ini di standard_join_search () itu sendiri tanpa menggunakan GEQO?


3
Sepertinya Anda ingin menerapkan petunjuk kueri. Itu semua baik dan bagus, tetapi Anda seharusnya tidak mengharapkan agar perubahan diterima di inti PostgreSQL karena komunitas proyek bukanlah apa yang Anda sebut penggemar berat permintaan petunjuk. Jika Anda serius tentang hal ini, Anda harus membaca sedikit kode perencana kueri dan Anda harus mengetahui cara meneruskan petunjuk Anda dari pengurai ke bawah melalui rewriter dan ke perencana. Saya tidak melihat jawaban cepat dan sederhana di sini. Apa yang ingin Anda lakukan pada akhirnya adalah memaksakan pilihan jalur tertentu dalam perencana / pengoptimal.
Craig Ringer

Ah, ya mereka skeptis tentang petunjuk permintaan. Saya telah melakukan pembacaan kode perencana dan sepertinya GEQO akan menjadi cara untuk meminimalkan perubahan pada inti yang ada.
user2761431

2
Apakah itu yang ingin Anda capai, menerapkan petunjuk kueri untuk memaksa bergabung dengan pemesanan? Jika demikian, lihat apakah ada orang lain yang sudah menerapkannya. Anda juga harus mempertimbangkan mengapa Anda membutuhkannya, mengapa perencana membuat pilihan yang salah sejak awal. Pertimbangkan untuk membuat test case yang lengkap dan melaporkan kinerja pgsql.
Craig Ringer

3
Ada pg_hint_plan : en.sourceforge.jp/projects/pghintplan , tetapi saya tidak menggunakannya. Satu dba mengatakan kepada saya bahwa itu berfungsi pada 9.2. Ada juga artikel dalam bahasa Rusia tentang hal itu habrahabr.ru/post/169751
ckorzhik

Jawaban:


1

Salah satu cara Anda dapat melakukan ini tanpa perlu dipusingkan dengan GEKO adalah dengan menggunakan CTE.

CTE adalah hambatan optimisasi, maka Anda dapat membungkus gabungan di dalam CTE dalam urutan yang Anda inginkan dan PG akan dipaksa untuk melakukannya.

Sebagai contoh jika kita ingin memaksa DB untuk pertama kali bergabung dengan t1 dengan t2 dan hanya dengan t4 kita dapat menjalankan sesuatu seperti:

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;

Ini akan menghasilkan:

                                  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)

Ini hanyalah sebuah contoh, Anda dapat mengubahnya sesuai kebutuhan - dalam hal apa pun PG tidak dapat mengubah urutan antara CTE yang berbeda.

Semoga bermanfaat :)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.