Почему Bitmap Scan быстрее, чем Index Scan, при извлечении умеренно большого процента таблицы в PostgreSQL?

Question

Автор Bitmap Scan описал разницу между Bitmap Heap Scan и Index Scan :

Простое сканирование индекса выбирает один указатель кортежа за раз из индекса, и немедленно посещает этот кортеж в таблице. Выборки растрового сканирования все кортежи-указатели из индекса за один раз, сортируют их, используя «растровую» структуру данных в памяти, а затем посещает кортежи таблиц в физический порядок расположения кортежей. Растровое сканирование улучшает местность ссылка на таблицу за счет дополнительных накладных расходов управлять структурой данных «точечный рисунок» --- и за счет того, что данные больше не извлекается в порядке индекса, что не имеет значения для вашего запрос, но имело бы значение, если бы вы сказали ORDER BY.

Вопросы:

1. Почему он снова сортирует извлеченные указатели кортежей, когда индекс уже отсортирован?

2. Как это сортировать с помощью растрового изображения? Я знаю, что такое растровое изображение, но я не понимаю, как его можно использовать для сортировки.

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

Answer 1

Основа хранилища Postgres состоит из страниц данных объемом 8 килобайт в типичной установке. Каждая страница данных обычно содержит много кортежей. Прочитайте подробности физического хранилища в руководстве .

«Растровое изображение» в растровом сканировании - это способ сбора указателей кортежей в сегменты страниц данных. В этом процессе порядок сортировки индекса обязательно теряется в пользу физического порядка сортировки. В «режиме с потерями» (который происходит только в том случае, если результат настолько велик или workmem настолько мал, что даже крошечная битовая карта не умещается) сохраняются только номера блоков и соответствующие индексы кортежей.

После этого каждую страницу данных посещают только один раз из хранилища для извлечения (возможно) нескольких кортежей и в физической последовательности, что также имеет значение для некоторых типов хранилищ. В режиме с потерями кортежи с каждой идентифицированной страницы должны быть отфильтрованы путем перепроверки состояния индекса; иначе кортежи можно извлекать напрямую, используя собранные индексы кортежей.

При индексном сканировании каждую страницу, возможно, придется посещать несколько раз, если несколько кортежей останутся на одной странице данных. Фактический процесс еще более сложный. Связанный:

• Postgres не использует индекс, когда сканирование индекса намного лучше
• Использование индекса для временной таблицы
• Строка «Recheck Cond:» в планах запросов с просмотром растрового индекса
• Как мне разложить ctid на номера страниц и строк?
• Не позволяйте PostgreSQL иногда выбирать неверный план запроса

На ваши вопросы:

1. Сортировка индекса теряется из-за сбора хитов и их считывания со страницы данных.

2. Следовательно, результат должен быть снова отсортирован на дополнительном этапе сортировки - если требуется порядок сортировки (например, ORDER BY).

3. Количество страниц данных, которые должны быть прочитаны, является наиболее важным фактором для общей производительности. Сканирование индекса растрового изображения уменьшает это число до минимума Благодаря более быстрому хранению преимущество сканирования растровых индексов уменьшается. Вот почему точные настройки стоимости имеют решающее значение для принятия правильного решения планировщиком запросов.