Понимание плана запроса EXPLAIN ANALYZE - PullRequest
Новая
       36

Понимание плана запроса EXPLAIN ANALYZE

0 голосов
/ 16 октября 2018

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

Merge Join (cost=31843.55..32194.92 rows=30215 width=36)
           (actual time=496.720..510.071 rows=38381 loops=1)
  Merge Cond: (movies.year = people.birth_year)
  -> Sort (cost=9905.45..9918.62 rows=5268 width=22)
     (actual time=151.781..152.690 rows=5634 loops=1) // <---- !!!! LOOKING HERE !!!!
       Sort Key: movies.year
       Sort Method: quicksort Memory: 729kB
     -> Seq Scan on movies (cost=0.00..9579.81 rows=5268 width=22)
        (actual time=145.826..149.340 rows=7640 loops=1) // <---- !!!! LOOKING HERE !!!!
          Filter: (title > ’y’::text)
          Rows Removed by Filter: 456425 // <---- !!!! LOOKING HERE !!!!
  -> Sort (cost=21936.87..21953.89 rows=6808 width=18)
     (actual time=344.918..347.980 rows=38465 loops=1)
       Sort Key: people.birth_year
       Sort Method: quicksort Memory: 423kB
     -> Seq Scan on people (cost=0.00..21503.44 rows=6808 width=18)
        (actual time=341.883..343.847 rows=4151 loops=1)
          Filter: (name > ’zeke’::text)
          Rows Removed by Filter: 1099324
Planning time: 0.450 ms
Execution time: 511.988 ms

Мне важно узнать оценку селективности для title > 'y'.
Этот план говорит: Rows Removed by Filter: 456425.

Итогоу нас есть 464065.

Поскольку фильтр удалял 456425 строк, мы выбрали 464065 - 456425 = 7640 строк, которые упоминаются в строке Seq Scan.

Но почему самый верхний Sort показывает фактические номера строк как 5634?Откуда оно?

Я подумал, что это может быть связано со второй операцией сортировки, но это совершенно разные ветви.

Есть ли способ узнать, умещаются ли таблицы в памяти или нет?План показывает, сколько памяти используется, но я не вижу их, указывающих, вписывается ли все это в память или нет.

1 Ответ

0 голосов
/ 17 октября 2018

Я не уверен, но я предполагаю, что «Объединение слиянием» использовало только 5634 строки из узла «Сортировка».

Выполнение PostgreSQL работает «по требованию», то есть строка результатазапрашивается из нижнего узла всякий раз, когда это требуется верхнему узлу.

И хотя для «Сортировки» определенно нужны все строки из «Сканирования по последовательности», объединение слиянием может быть завершено до того, как будут прочитаны все доступные отсортированные строки.

Это был не ваш вопрос, но для ускорения запроса вам нужны индексы people (name) и movies (title).

Чтобы узнать, кэшируются ли ваши данные, используйте EXPLAIN (ANALYZE, BUFFERS).Затем вы увидите количество блоков, которые были найдены в кеше (попадание) и количество блоков, прочитанных из операционной системы (чтение).Однако обратите внимание, что данные для чтения могут поступать из кэша файловой системы.

...