Меня интересует понимание того, как Postgres читает страницы с диска / кэша при использовании индекса.
Рассмотрим запрос к индексированной таблице из одного столбца целых чисел:
select i
into numbers
from generate_series(1, 200000) s(i);
create index idx on numbers(i);
explain (buffers, analyse)
select * from numbers where i = 456789; -- random row
Этот единственный индекс-только поиск требует 3 чтения страницы в этой таблице строк 200k (Buffers: shared hit=3):
Index Only Scan using idx on numbers (cost=0.42..8.44 rows=1 width=4) (actual time=0.010..0.010 rows=0 loops=1)
Index Cond: (i = 456789)
Heap Fetches: 0
Buffers: shared hit=3
Planning Time: 0.043 ms
Execution Time: 0.022 ms
Ожидается ли это? К чему относятся 3 страницы? Это просто число страниц индекса, которые нужно было прочитать, чтобы пройти через B-дерево?
Справочная информация : я пытаюсь настроить рекурсивный CTE, который просматривает связанный списокструктура хранится в одной таблице как родительско-дочерние отношения / дерево смежности. Рекурсивный раздел запроса - это очень простой поиск по индексу, аналогичный приведенному выше. Каждый «цикл» рекурсивного CTE приводит к 3 чтениям страницы (как указано выше), в которых и лежит большая часть стоимости запроса. Может быть невозможно сделать это более эффективным, но мне было интересно, можно ли это как-то улучшить (в настоящее время ~ 30000 считываний страниц для цепочки узлов 10 Кб, ~ 25 мс кэшировано).