Комментарии 4
Слон-страйдер
Пишите еще пожалуйста. Вообще довольно интересно получаеться, последний запрос после добавления индексов выдает explain:
Делаем:
vacuum analyze test;
И explain получается как у автора. Получается что пока не запустится автовакуум, после большого количества DDL запросов, запрос может строиться не оптимальным способом ?
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 запросов, запрос может строиться не оптимальным способом ?
Да, analyze полезно делать после заполнения какой-то таблицы или большого удаления, поскольку обновляется статистика для планировщика. Очень полезный прием, когда надо какую-то статистику обновить, например. Берем сырые данные, кладем в temporary таблицу с нужным партиционированием, строим индексы, делаем analyze и работаем с данными.
Очень полезная статья, спасибо.
Bitmap Index Scans объединяет оба случая: когда вам нужно много строк из таблицы, но не все, и когда строки, которые вы будете возвращать, находятся не в одном блоке (что было бы оправдано, если бы я производил операцию “… where id < ...").
Можете пояснить, что имеется в виду под "находятся не в одном блоке"? Ведь по сути индекс на id отличается от индекса на i только ограничением на уникальность. Или играет роль, то что мы добавляем строки, монотонно увеличивая id?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объясняя необъяснимое. Часть 2