Bitmap Index Scan ve Bitmap Heap Scan

Giriş

Açıklaması şöyle

.. a Bitmap Heap Scan always works in tandem with Bitmap Index Scan to speed things up.

Açıklaması şöyle

Bitmap Index Scan scans the index first to create a bitmap of which pages need to be fetched, and Bitmap Heap Scan then uses the bitmap to fetch the data from the pages.

Neden Lazım

Açıklaması şöyle. Yani elimizde bir indeks varsa ancak sıralı değilse - örneğin indeks text içinse - kullanılır.

.... index scans cause random I/O if there is no ordering to the rows (name is text content). This is costly in rotational hard drives. To solve this, the Planner takes a two-stage approach. The Bitmap Index Scan constructs a data structure called a bitmap from the index present and represents the approximate location of pages in the disk and feeds it to the parent node, i.e., Bitmap Heap Scan, which then uses that to fetch the pages/rows.

Örnek

Şöyle yaparız. Burada name alanı için indeks yaratılıyor

CREATE INDEX name_str_idx ON fake_data USING BTREE(name);

Sorgu için şöyle yaparız

EXPLAIN ANALYZE SELECT * FROM fake_data WHERE 
 fake_data.name = 'David';

Örnek

Şöyle yaparız

CREATE INDEX idx weather_type ON weather(event_type); 

Bitmap Heap Scan on weather (cost=4.36..37.56 rows=11 width=622) (actual time=0.500..2.300 rows=11 loops=1)
Recheck Cond: ((event type)::text = 'Winter Storm'::text)
Heap Blocks: exact=6
-> Bitmap Index Scan on idx weather type (cost=0.00..4.36 rows=11] width =0) (actual time=0.400..0.400 rows=11 loops=1)
    Index Cond: ((event type)::text = 'Winter Storm'::text)
Planning Time: 23.300 ms
Execution Time: 7.200 ms
(7 rows)

Örnek - Bitmap Or

Eğer iki tane indeks varsa kullanılır. Elimizde şu anda id ve name için iki tane indeks var. 

Sorgu için şöyle yaparız

EXPLAIN ANALYZE SELECT * FROM fake_data WHERE 
 fake_data.id = 1000 OR fake_data.name = 'David';

Örnek - Bitmap And

Eğer iki tane indeks varsa kullanılır. Elimizde şu anda id ve name için iki tane indeks var. 

Sorgu için şöyle yaparız

EXPLAIN ANALYZE SELECT * FROM fake_data WHERE 
 fake_data.id <= 1000 OR fake_data.name = 'David';

5. Parallel Scans

Açıklaması şöyle

Sequential Scans are the slowest of all the plans we have seen so far because there is nothing to optimize there. The Planner goes over the data sequentially and tries to find the result. PostgreSQL optimizes this further by adding parallelism in the queries.