Объясняя необъяснимое. Часть 2

[AndersonDunai]

Слон-страйдер

[itcoder]

Пишите еще пожалуйста. Вообще довольно интересно получаеться, последний запрос после добавления индексов выдает explain:

explain analyze select * from test where j < 50000000 and i < 50000000 and h > 950000000;

Bitmap Heap Scan on test  (cost=99.57..731.89 rows=580 width=16) (actual time=4.173..7.049 rows=17 loops=1)
   Recheck Cond: (i < 50000000)
   Filter: ((j < 50000000) AND (h > 950000000))
   Rows Removed by Filter: 5026
   Heap Blocks: exact=541
   ->  Bitmap Index Scan on i1  (cost=0.00..99.43 rows=5218 width=0) (actual time=3.926..3.926 rows=5043 loops=1)
         Index Cond: (i < 50000000)
 Planning time: 0.137 ms
 Execution time: 7.099 ms
(9 rows)

Делаем:
vacuum analyze test;
И explain получается как у автора. Получается что пока не запустится автовакуум, после большого количества DDL запросов, запрос может строиться не оптимальным способом ?

[rdruzyagin]

Да, analyze полезно делать после заполнения какой-то таблицы или большого удаления, поскольку обновляется статистика для планировщика. Очень полезный прием, когда надо какую-то статистику обновить, например. Берем сырые данные, кладем в temporary таблицу с нужным партиционированием, строим индексы, делаем analyze и работаем с данными.

[Anshelen]

Очень полезная статья, спасибо.

Bitmap Index Scans объединяет оба случая: когда вам нужно много строк из таблицы, но не все, и когда строки, которые вы будете возвращать, находятся не в одном блоке (что было бы оправдано, если бы я производил операцию “… where id < ...").

Можете пояснить, что имеется в виду под "находятся не в одном блоке"? Ведь по сути индекс на id отличается от индекса на i только ограничением на уникальность. Или играет роль, то что мы добавляем строки, монотонно увеличивая id?