Модифікація до GEQO (Оптимізація генетичних запитів) PostgreSQL

Мені потрібно реалізувати функціонал, який відповідає функціоналу GEQO PostgreSQL. Я розумію, що підхід GEQO полягає в кодуванні планів запитів як цілих рядків, і GEQO генерує ці можливі послідовності приєднання. Джерело: http://www.postgresql.org/docs/9.3/static/geqo-pg-intro.html

Моє запитання: як змінити функцію GEQO, якщо я остаточно знаю правильну послідовність приєднання, щоб мені не довелося шукати різні послідовності з'єднання. Наприклад, якби я знав, що найкращий спосіб вступу в 4 відносини - 4-1-3-2, мені не потрібно перевіряти інші перестановки.

Немає хороших матеріалів про те, як GEQO реалізується в PostgreSQL. PostgreSQL дає лише загальний вигляд функціональності GEQO, але не дуже пояснює.

Або я можу досягти цієї функціональності в самому стандарті_join_search () без використання GEQO?

postgresql optimization

— користувач2761431
джерело

Це здається, що ви хочете реалізувати підказки для запитів. Це все добре і добре, але не варто сподіватися, що зміни приймуться в ядрі PostgreSQL, оскільки спільнота проектів - це не те, що ви б назвали великим шанувальником підказок запитів. Якщо ви серйозно ставитесь до цього, вам потрібно буде прочитати трохи коду планувальника запитів, і вам потрібно буде з'ясувати, як передати свої підказки з аналізатора вниз через переписувач і в планувальник. Я не бачу тут швидкої та простої відповіді. Що ви хочете в кінцевому підсумку зробити, це змусити певний вибір шляху у планувальнику / оптимізаторі.

— Крейг Рінгер

Ах, так, вони скептично ставляться до підказок щодо запитів. Я прочитав код планувальника, і здавалося, що GEQO буде способом мінімізувати зміни до існуючого ядра.

— користувач2761431

Це те, чого ви намагаєтесь досягти, реалізувати підказки запитів, щоб змусити приєднатись до замовлення? Якщо так, то погляньте, чи хтось ще це вже реалізував. Ви також повинні врахувати, для чого це потрібно, чому планувальник робить неправильний вибір в першу чергу. Подумайте про створення автономного тестового випадку та звітування до pgsql-performance.

— Крейг Рінгер

Є pg_hint_plan : en.sourceforge.jp/projects/pghintplan , але я не використовував його. Один dba сказав мені, що працює на 9.2. Є також стаття російською мовою про це habrahabr.ru/post/169751

— ckorzhik

Один із способів зробити це без необхідності возитися з GEKO - це використовувати CTE.

CTE є бар'єрами для оптимізації, отже, ви можете зафіксувати з'єднання всередині CTE в потрібному порядку і PG буде змушений це робити.

Наприклад, якщо ми хочемо змусити БД спочатку приєднати t1 до t2, а вже потім з t4, ми могли б запустити щось на кшталт:

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;

Це призведе до:

                                  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)

Це лише приклад, ви можете змінювати його за потребою - у будь-якому випадку PG не може змінити порядок між різними CTE.

Сподіваюся, це допомагає :)

— cohenjo
джерело