Понимание Postgres объяснить план - PullRequest
Новая
       23

Понимание Postgres объяснить план

0 голосов
/ 07 мая 2020

Я пытаюсь понять план Postgres объяснения, использующий этот веб-сайт (http://explain.depesz.com).

Это мой план: 

Unique  (cost=795.43..800.89 rows=546 width=23) (actual time=0.599..0.755 rows=620 loops=1)
  ->  Sort  (cost=795.43..796.79 rows=546 width=23) (actual time=0.598..0.626 rows=620 loops=1)
        Sort Key: m.member_id, c.total_charged_amt DESC, c.claim_status
        Sort Method: quicksort  Memory: 73kB
        ->  Nested Loop  (cost=9.64..770.60 rows=546 width=23) (actual time=0.023..0.342 rows=620 loops=1)
              ->  Bitmap Heap Scan on member m  (cost=9.22..222.50 rows=63 width=8) (actual time=0.016..0.024 rows=62 loops=1)
                    Recheck Cond: (((member_id >= 1584161838) AND (member_id <= 1584161898)) OR (member_birth_dt = '1978-03-13'::date))
                    Heap Blocks: exact=3
                    ->  BitmapOr  (cost=9.22..9.22 rows=63 width=0) (actual time=0.013..0.013 rows=0 loops=1)
                          ->  Bitmap Index Scan on member_pkey  (cost=0.00..4.31 rows=2 width=0) (actual time=0.007..0.007 rows=61 loops=1)
                                Index Cond: ((member_id >= 1584161838) AND (member_id <= 1584161898))
                          ->  Bitmap Index Scan on idx_dob  (cost=0.00..4.88 rows=61 width=0) (actual time=0.006..0.006 rows=1 loops=1)
                                Index Cond: (member_birth_dt = '1978-03-13'::date)
              ->  Index Scan using idx_memberid on claim c  (cost=0.42..8.60 rows=10 width=23) (actual time=0.001..0.003 rows=10 loops=62)
                    Index Cond: (member_id = m.member_id)
Planning Time: 0.218 ms
Execution Time: 0.812 ms

План также доступен по следующей ссылке: https://explain.depesz.com/s/Qzau.

У меня есть следующие вопросы:

  1. Bitmap Index Scans, который выполняется за 0,007 и 0,006 с соответственно, выполняется параллельно из-за отступа.

    Так почему Bitmapor начинается с 0,013 с? Почему он добавляет время обоих своих детей? Время начала Bitmapor должно быть максимумом из двух его дочерних элементов. Таким образом, в идеале эксклюзивное время из Bitmapor должно быть 0,006 (0,013-0,007), но это 0 (0,013-0,007-0,006)

  2. Bitmap Heap Scan и index scan являются дочерними элементами Nested Loop и выполняются за 0,024 и 0,186 секунды соответственно.

    Из-за отступа я предполагаю, что эти 2 дочерних элемента работают параллельно. Таким образом, родительское исключительное время должно быть 0,156 (0,342-0,186), но вместо этого оно равно 0,132 (0,342-0,186-0,24).

Насколько я понимаю, мы должны вычтите максимум дочерних таймингов (поскольку они работают параллельно), чтобы получить исключительное время, проведенное в узле. Но вместо этого он складывает дочерние тайминги, а затем вычитает сумму из конечного времени родительского, чтобы получить исключительное время. Я неправильно понял планы объяснения?

Любая помощь действительно приветствуется, поскольку я совершенно запутался в их интерпретации.

1 Ответ

1 голос
/ 07 мая 2020

Как сказала лошадь, параллельной обработки не требуется. Если бы был задействован параллельный запрос, вы бы увидели узел Gather, который собирает результаты.

Отступ визуализирует график плана выполнения запроса: 

                         Unique
                           |
                          Sort
                           |
                      Nested Loop
                        /      \
          Bitmap Heap Scan    Index Scan
                  |
              Bitmap Or
               /     \
Bitmap Index Scan   Bitmap Index Scan

Это объясняет, зачем объяснять. depesz.com рассчитывает эксклюзивное время так, как он это делает. Обратите внимание, что это всего лишь лучшая попытка, а не абсолютная истина, потому что (например) «растровое изображение или» не требует нулевого времени. Но объяснить.depesz.com может только go по числам, полученным от EXPLAIN.

...