PostgreSQL'in GEQO (Genetik Sorgu Optimizasyonu) üzerinde değişiklik

PostgreSQL GEQO işlevselliği ile uyumlu bir işlevsellik uygulamak gerekir. GEQO yaklaşımının sorgu planlarını tamsayı dizeleri olarak kodlamak olduğunu ve GEQO'nun bu olası birleştirme dizilerini rastgele oluşturduğunu biliyorum. Kaynak: http://www.postgresql.org/docs/9.3/static/geqo-pg-intro.html

Benim sorum: GEQO işlevini doğru birleştirme sırasını kesin olarak biliyorsam nasıl değiştirilirim, böylece farklı birleştirme dizilerini aramak zorunda kalmam. Örneğin, 4 ilişkiye katılmanın en iyi yolunun 4-1-3-2 olduğunu bilsem, diğer permütasyonları kontrol etmeme gerek kalmaz.

GEQO'nun PostgreSQL'de nasıl uygulandığı konusunda iyi bir materyal bulunmamaktadır. PostgreSQL sadece GEQO işlevselliğinin genel görünümünü vermektedir, ancak fazla bir şey açıklamamaktadır.

Veya bu işlevi GEQO kullanmadan standard_join_search () içinde elde edebilir miyim?

postgresql optimization

— user2761431
kaynak

Sorgu ipuçlarını uygulamak istediğiniz anlaşılıyor. Her şey iyi ve güzel, ancak PostgreSQL çekirdeğinde değişikliği kabul etmeyi beklememelisiniz, çünkü proje topluluğu, sorgu ipuçlarının büyük bir hayranı olarak adlandırdığınız şey değildir. Bu konuda ciddi iseniz, biraz sorgu planlayıcısı kodunu okumanız ve ipuçlarınızı ayrıştırıcıdan yeniden yazıcıdan planlayıcıya nasıl geçireceğinizi anlamanız gerekir. Burada hızlı ve basit bir cevap görmüyorum. Sonunda yapmak istediğiniz şey, planlayıcı / optimize edicide belirli bir yol seçimini zorlamaktır.

— Craig Ringer

Ah, evet, sorgu ipuçlarına kuşkuyla bakıyorlar. Planlayıcı kodunu okudum ve GEQO mevcut çekirdekteki değişiklikleri en aza indirmenin bir yolu gibi görünüyordu.

— user2761431

Katılmaya zorlamak için sorgu ipuçlarını uygulamak için elde etmeye çalıştığınız şey bu mu? Öyleyse, başka bir kişinin zaten uygulayıp uygulamadığına bakın. Ayrıca neden ihtiyacınız olduğunu, planlamacının neden yanlış seçimler yaptığını da düşünmelisiniz. Bağımsız bir test senaryosu oluşturmayı ve pgsql-performansına rapor vermeyi düşünün.

— Craig Ringer

Orada pg_hint_plan : en.sourceforge.jp/projects/pghintplan ama bunu kullanmadım. Bir dba bana bunun 9.2 üzerinde çalıştığını söyledi. Rusça da bu konuda bir makale var habrahabr.ru/post/169751

— ckorzhik

GEKO ile uğraşmak zorunda kalmadan bunu yapmanın bir yolu CTE kullanmaktır.

CTE optimizasyon engelleridir, bu nedenle CTE'lerin içindeki birleşimleri istediğiniz sırayla sarabilirsiniz ve PG bunu yapmak zorunda kalacaktır.

Örneğin, DB'yi ilk olarak t1'i t2 ile birleştirmeye zorlamak istiyorsak ve ancak o zaman t4 ile çalışabiliriz:

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;

Bunun sonucu:

                                  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)

Bu sadece bir örnektir, gerektiğinde değiştirebilirsiniz - her durumda PG farklı CTE'ler arasındaki sırayı değiştiremez.

Umarım yardımcı olur :)

— cohenjo
kaynak