Блог

В моей таблице содержится 5500000 тестовых записей (Postgres 12). У меня есть неопределенность из-за больших затрат, когда я использую индекс покрытия в своих таблицах.

Итак, я создаю индекс:

 create index concurrently idx_log_type
    on logs (log_type)
    include (log_body);
 

После того, как я выполню запрос:

 explain (analyze)
select log_body
from logs where log_type = 1
limit 100;
 

Я получаю результат:

 Limit  (cost=0.43..5.05 rows=100 width=33) (actual time=0.118..0.138 rows=100 loops=1)
    - ->  Index Only Scan using idx_log_type on logs  (cost=0.43..125736.10 rows=2720667 width=33) (actual time=0.107..0.118 rows=100 loops=1)
        Index Cond: (log_type = 1)
        Heap Fetches: 0
Planning Time: 0.558 ms
Execution Time: 0.228 ms
 

На первый взгляд, это так хорошо, но диапазон затрат очень велик.
Это нормально или вы должны оптимизировать?

Это артефакт EXPLAIN : он показывает стоимость полного индексного сканирования, как если бы их не LIMIT было. Но весь план рассчитан правильно.

Таким образом, вы можете игнорировать высокий верхний предел стоимости при индексном сканировании.