Розуміння "сканування бітної карти" та "сканування індексу растрової карти"

Спробую пояснити свої непорозуміння наступним прикладом.

Я не розумів основ цього Bitmap Heap Scan Node. Розглянемо запит, SELECT customerid, username FROM customers WHERE customerid < 1000 AND username <'user100';план якого такий:

Bitmap Heap Scan on customers  (cost=25.76..61.62 rows=10 width=13) (actual time=0.077..0.077 rows=2 loops=1)
  Recheck Cond: (((username)::text < 'user100'::text) AND (customerid < 1000))
  ->  BitmapAnd  (cost=25.76..25.76 rows=10 width=0) (actual time=0.073..0.073 rows=0 loops=1)
        ->  Bitmap Index Scan on ix_cust_username  (cost=0.00..5.75 rows=200 width=0) (actual time=0.006..0.006 rows=2 loops=1)
              Index Cond: ((username)::text < 'user100'::text)
        ->  Bitmap Index Scan on customers_pkey  (cost=0.00..19.75 rows=1000 width=0) (actual time=0.065..0.065 rows=999 loops=1)
              Index Cond: (customerid < 1000)

Моє розуміння цього вузла :

Як пояснено там , bitmap heap scanзчитування блоків таблиці відбувається в послідовному порядку, тому вона не створює накладних таблиць з доступом до довільної таблиці, що відбувається просто як просто Index Scan.

Після Index Scanцього PostgreSQL не знає, як оптимально отримати рядки, щоб уникнути зайвого heap blocks reads(або hitsякщо є гарячий кеш). Отже, щоб зрозуміти це, вона генерує структуру ( Bitmap Index Scan), яку називають bitmapу моєму випадку, генеруючи два растрових карти індексів та виконуючи їх BITWISE AND. Оскільки растровий файл був створений, тепер він може оптимально читати таблицю в послідовному порядку, уникаючи зайвого heap I/O-operations.

Це місце, де надходить багато питань.

ПИТАННЯ: У нас є лише растрова карта. Як PostgreSQL за допомогою растрового зображення знає що-небудь про фізичний порядок рядків? Або створює растрову карту, щоб будь-який її елемент можна було легко перенести на вказівник на сторінку? Якщо так, це пояснює все, але це лише моє здогадування.

Отже, чи можемо ми сказати просто, що bitmap heap scan -> bitmap index scanце як послідовне сканування, але лише відповідна частина таблиці?

Як PostgreSQL за допомогою растрового зображення знає що-небудь про фізичний порядок рядків?

Растровий малюнок - це один біт на групі купи. Сканування індексу растрових зображень встановлює біти на основі адреси сторінки, на яку вказує вхід індексу.

Тож, коли йдеться про сканування бітової карти, він просто виконує лінійну сканування таблиці, читаючи растрову карту, щоб побачити, чи слід турбувати певну сторінку чи шукати її.

Або створює растрову карту, щоб будь-який її елемент можна було легко перенести на вказівник на сторінку?

Ні, растровий файл відповідає 1: 1 на купі сторінок.

Я написав більше про це тут .

Гаразд, схоже, ви можете нерозуміти, що означає "растрова карта" в цьому контексті.

Це не маленький рядок, як "101011", створений для кожної купи сторінки, чи кожного прочитаного індексу, або будь-якого іншого.

Весь растровий малюнок - це один бітовий масив із стільки бітів, скільки сторінок купи у скануванні.

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

Другий і подальший сканування біт-мап робить те саме, що й інші індекси та умови пошуку на них.

Тоді кожен растровий файл об'єднується разом. Отримана растрова карта має один біт для кожної сторінки купи, де біти є істинними лише в тому випадку, якщо вони були правдивими у всіх окремих скануваннях растрових індексів, тобто умова пошуку, що відповідає кожному скануванню індексу. Це єдині купи сторінок, які нам потрібно намагатись завантажити та вивчити. Оскільки кожна сторінка купи може містити кілька рядків, то нам доведеться вивчити кожен рядок, щоб побачити, чи відповідає вона всім умовам - саме про це йдеться у частині "Перевірити умову".

Одне важливе, що потрібно розуміти при всьому цьому, це те, що кортежна адреса у вхідному покажчику індексу вказує на рядок ctid, який є комбінацією номера сторінки купи та зсуву в межах купи. Сканування індексу растрових зображень ігнорує зсуви, оскільки вона все одно перевірятиме всю сторінку та встановлює біт, якщо будь-який рядок на цій сторінці відповідає умові.

Графічний приклад

Heap, one square = one page:
+---------------------------------------------+
|c____u_____X___u___X_________u___cXcc______u_|
+---------------------------------------------+
Rows marked c match customers pkey condition.
Rows marked u match username condition.
Rows marked X match both conditions.


Bitmap scan from customers_pkey:
+---------------------------------------------+
|100000000001000000010000000000000111100000000| bitmap 1
+---------------------------------------------+
One bit per heap page, in the same order as the heap
Bits 1 when condition matches, 0 if not

Bitmap scan from ix_cust_username:
+---------------------------------------------+
|000001000001000100010000000001000010000000010| bitmap 2
+---------------------------------------------+

Після створення бітових зображень побіжно І виконується на них:

+---------------------------------------------+
|100000000001000000010000000000000111100000000| bitmap 1
|000001000001000100010000000001000010000000010| bitmap 2
 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
|000000000001000000010000000000000010000000000| Combined bitmap
+-----------+-------+--------------+----------+
            |       |              |
            v       v              v
Used to scan the heap only for matching pages:
+---------------------------------------------+
|___________X_______X______________X__________|
+---------------------------------------------+

Тоді скачування купового растрового зображення шукає початок кожної сторінки та читає сторінку:

+---------------------------------------------+
|___________X_______X______________X__________|
+---------------------------------------------+
seek------->^seek-->^seek--------->^
            |       |              |
            ------------------------
            only these pages read

і кожна сторінка, яку читають, потім повторно перевіряється на умову, оскільки на ній може бути> 1 рядок на сторінці, і не всі обов'язково відповідають умові.

Будь ласка, зверніться до мого запису в блозі https://rajeevrastogi.blogspot.in/2018/02/bitmap-scan-in-postgresql.html?showComment=1518410565792#c4647352762092142586, щоб отримати детальну характеристику растрового сканування в PostgreSQL.

Загальний швидкий огляд функціональних можливостей сканування растрових зображень:

1. Сканування Bitmap Heap скануйте кортеж з Bitmap Index Scan.

2. Bitmap Index Scan сканує індекс відповідно до умови майже так само, як і в звичайному індексі сканування. Але замість того, щоб повертати TID (що складається із сторінки без сторінки та зміщення всередині цього), що відповідає даних купи, він додає ці TID у растровій карті. Для простого розуміння, ви можете вважати, що ця растрова карта містить хеш усіх сторінок (хеш на основі сторінки №), і кожен запис сторінки містить масив усіх зрушень на цій сторінці.

3. Потім Bitmap Heap Scan зчитується через растрову карту, щоб отримати дані купи, що відповідають збереженому номеру сторінки та зміщення. Потім він перевіряє видимість, кваліфікацію тощо та повертає кортеж на основі результатів усіх цих перевірок.