Чому PostgreSQL вибирає дорожче замовлення на приєднання?

PostgreSQL з використанням за замовчуванням плюс

default_statistics_target=1000
random_page_cost=1.5

Версія

PostgreSQL 10.4 on x86_64-pc-linux-musl, compiled by gcc (Alpine 6.4.0) 6.4.0, 64-bit

Я пилососив і аналізував. Запит дуже простий:

SELECT r.price
FROM account_payer ap
  JOIN account_contract ac ON ap.id = ac.account_payer_id
  JOIN account_schedule "as" ON ac.id = "as".account_contract_id
  JOIN schedule s ON "as".id = s.account_schedule_id
  JOIN rate r ON s.id = r.schedule_id
WHERE ap.account_id = 8

Кожен idстовпець є первинним ключем, і все, що з'єднується, - це зв'язок із зовнішнім ключем, і кожен зовнішній ключ має індекс. Плюс індекс для account_payer.account_id.

На повернення 76k рядків потрібно 3,93.

Merge Join  (cost=8.06..83114.08 rows=3458267 width=6) (actual time=0.228..3920.472 rows=75548 loops=1)
  Merge Cond: (s.account_schedule_id = "as".id)
  ->  Nested Loop  (cost=0.57..280520.54 rows=6602146 width=14) (actual time=0.163..3756.082 rows=448173 loops=1)
        ->  Index Scan using schedule_account_schedule_id_idx on schedule s  (cost=0.14..10.67 rows=441 width=16) (actual time=0.035..0.211 rows=89 loops=1)
        ->  Index Scan using rate_schedule_id_code_modifier_facility_idx on rate r  (cost=0.43..486.03 rows=15005 width=10) (actual time=0.025..39.903 rows=5036 loops=89)
              Index Cond: (schedule_id = s.id)
  ->  Materialize  (cost=0.43..49.46 rows=55 width=8) (actual time=0.060..12.984 rows=74697 loops=1)
        ->  Nested Loop  (cost=0.43..49.32 rows=55 width=8) (actual time=0.048..1.110 rows=66 loops=1)
              ->  Nested Loop  (cost=0.29..27.46 rows=105 width=16) (actual time=0.030..0.616 rows=105 loops=1)
                    ->  Index Scan using account_schedule_pkey on account_schedule "as"  (cost=0.14..6.22 rows=105 width=16) (actual time=0.014..0.098 rows=105 loops=1)
                    ->  Index Scan using account_contract_pkey on account_contract ac  (cost=0.14..0.20 rows=1 width=16) (actual time=0.003..0.003 rows=1 loops=105)
                          Index Cond: (id = "as".account_contract_id)
              ->  Index Scan using account_payer_pkey on account_payer ap  (cost=0.14..0.21 rows=1 width=8) (actual time=0.003..0.003 rows=1 loops=105)
                    Index Cond: (id = ac.account_payer_id)
                    Filter: (account_id = 8)
                    Rows Removed by Filter: 0
Planning time: 5.843 ms
Execution time: 3929.317 ms

Якщо я встановлю join_collapse_limit=1, це займе 0,16 секунди, 25-кратне прискорення.

Nested Loop  (cost=6.32..147323.97 rows=3458267 width=6) (actual time=8.908..151.860 rows=75548 loops=1)
  ->  Nested Loop  (cost=5.89..390.23 rows=231 width=8) (actual time=8.730..11.655 rows=66 loops=1)
        Join Filter: ("as".id = s.account_schedule_id)
        Rows Removed by Join Filter: 29040
        ->  Index Scan using schedule_pkey on schedule s  (cost=0.27..17.65 rows=441 width=16) (actual time=0.014..0.314 rows=441 loops=1)
        ->  Materialize  (cost=5.62..8.88 rows=55 width=8) (actual time=0.001..0.011 rows=66 loops=441)
              ->  Hash Join  (cost=5.62..8.61 rows=55 width=8) (actual time=0.240..0.309 rows=66 loops=1)
                    Hash Cond: ("as".account_contract_id = ac.id)
                    ->  Seq Scan on account_schedule "as"  (cost=0.00..2.05 rows=105 width=16) (actual time=0.010..0.028 rows=105 loops=1)
                    ->  Hash  (cost=5.02..5.02 rows=48 width=8) (actual time=0.178..0.178 rows=61 loops=1)
                          Buckets: 1024  Batches: 1  Memory Usage: 11kB
                          ->  Hash Join  (cost=1.98..5.02 rows=48 width=8) (actual time=0.082..0.143 rows=61 loops=1)
                                Hash Cond: (ac.account_payer_id = ap.id)
                                ->  Seq Scan on account_contract ac  (cost=0.00..1.91 rows=91 width=16) (actual time=0.007..0.023 rows=91 loops=1)
                                ->  Hash  (cost=1.64..1.64 rows=27 width=8) (actual time=0.048..0.048 rows=27 loops=1)
                                      Buckets: 1024  Batches: 1  Memory Usage: 10kB
                                      ->  Seq Scan on account_payer ap  (cost=0.00..1.64 rows=27 width=8) (actual time=0.009..0.023 rows=27 loops=1)
                                            Filter: (account_id = 8)
                                            Rows Removed by Filter: 24
  ->  Index Scan using rate_schedule_id_code_modifier_facility_idx on rate r  (cost=0.43..486.03 rows=15005 width=10) (actual time=0.018..1.685 rows=1145 loops=66)
        Index Cond: (schedule_id = s.id)
Planning time: 4.692 ms
Execution time: 160.585 ms

Ці результати для мене мало сенсу. Перший має (дуже високу) вартість 280 500 для вкладених циклів приєднання для індексів розкладу та швидкості. Чому PostgreSQL навмисно обирає спочатку дуже дороге приєднання?

Додаткову інформацію запитують через коментарі

Чи rate_schedule_id_code_modifier_facility_idxє складний індекс?

Це є, schedule_idбудучи першою колоною. Я зробив це виділеним індексом, і його обирає планувальник запитів, але це не впливає на продуктивність або іншим чином впливає на план.

— Пол Дрейпер
джерело

Чи можете ви змінити налаштування default_statistics_targetта random_page_costповернутись до їх значень за замовчуванням? Що відбувається, коли ти піднімаєшся default_statistics_targetдалі? Чи можете ви створити Скрипку БД (на dbfiddle.uk) і спробувати відтворити проблему там?

— Colin 't Hart

Чи можете ви перевірити фактичну статистику, щоб побачити, чи є щось перекошене / дивне у ваших даних? postgresql.org/docs/10/static/planner-stats.html

— Colin 't Hart

Яке поточне значення параметра work_mem? Змінивши це дає різні часові позначки?

— eppesuig

Здається, або ваші статистичні дані не точні (запустіть вакуумний аналіз, щоб оновити їх), або у вас є відповідні стовпці у вашій моделі (і тому вам потрібно буде виконати, create statisticsщоб повідомити планувальник про цей факт).

join_collapseПараметр дозволяє планувальник переставити з'єднує тому він виконує спочатку один , який витягує менше даних. Але для продуктивності ми не можемо дозволити планувальникові робити це за запитом з великою кількістю приєднань. За замовчуванням встановлено 8 приєднань макс. Встановивши його в 1, ви просто відключите цю здатність.

Тож як postgres передбачає, скільки рядків має отримати цей запит? Він використовує статистику для оцінки кількості рядків.

Що ми можемо побачити у ваших планах пояснення, це те, що існує кілька неточних оцінок числа рядків (перше значення - оцінка, друге - дійсне).

Наприклад, тут:

Materialize  (cost=0.43..49.46 rows=55 width=8) (actual time=0.060..12.984 rows=74697 loops=1)

Планувальник підрахував отримати 55 рядів, коли він фактично отримав 74697.

Що я б робив (якби я був у вашому взутті):

analyze п'ять таблиць для оновлення статистики
Повтор explain analyze
Подивіться на різницю між оціночними номерами рядків і фактичними номерами рядків
Якщо підрахунок номерів рядків правильний, можливо, план змінився і є більш ефективним. Якщо все в порядку, ви можете розглянути можливість зміни налаштувань автовакууму, тому аналізуйте (і виконайте вакуум) частіше
Якщо оцінки номерів рядків все ще помиляються, здається, що ви співвідносили дані у своїй таблиці (порушення третьої нормальної форми). Ви можете розглянути питання про їх оголошення CREATE STATISTICS(документація тут )

Якщо вам потрібна додаткова інформація про кошторис рядків та його обчислення, ви знайдете все необхідне в конфіденційній бесіді Томаса Вондра "Створити статистику - для чого це?" (слайди тут )

— Архена
джерело