План выполнения с неправильными затратами при использовании индекса

Question

Может ли кто-нибудь помочь мне понять, почему postgresql пропустил несколько оценок стоимости.

Я провожу эксперимент с 22 запросами из TPCH Benchmark [1], чтобы проверить производительность индексов в запросах.

Из 22 запросов только 5 были проверены, что оптимизатор использовал вторичные индексы. В другом эксперименте 5 указанных запросов были выполнены в базе данных без наличия индексов, чтобы определить, увеличится ли время выполнения из-за отсутствия индексов.

Но, к моему удивлению, эксперимент без присутствия индексов в базе данных был быстрее, чем использование индексов (для 22 запросов).

Я хотел бы понять, потому что параметр общей стоимости был неправильным во всех случаях, то есть все запросы, которые потратили больше всего времени, указали на более низкую стоимость - во всех 5 случаях, что на мой взгляд неверно.

Смотрите ниже, что первая строка относится к запросу 6, который вы использовали Index, стоимость была 3335809, ниже, чем стоимость 5255959, тот же запрос 6, который не использовал индекс.

Также смотрите время, проведенное. Запрос, в котором использовался индекс, занимал 7 минут, а без индексации - 55 секунд. Такое поведение распространяется на другие случаи.

Мой вопрос: почему общая стоимость (план выполнения) неправильно рассчитывает стоимость для всех случаев, когда у вас есть индексы?

Indexes |Query|Time Spent    |Total Cost
============================================
Sim      6    00:07:56        3335809.61
Nao      6    00:00:55        5255959.00
Sim      7    00:09:16        5847359.97
Nao      7    00:02:08        6793148.45
Sim     10    00:07:04        40743017.17
Nao     10    00:02:14        41341406.62
Sim     15    00:10:03        6431359.90
Nao     15    00:01:56        9608659.87
Sim     20    00:12:48        8412159.69
Nao     20    00:05:49        9537835.93

Выполните запрос 6 и объясните его анализ с индексами и без них.

select
    sum(l_extendedprice * l_discount) as revenue
from
    lineitem
where
    l_shipdate >= date '1995-01-01'
    and l_shipdate < date '1995-01-01' + interval '1' year
    and l_discount between 0.09 - 0.01 and 0.09 + 0.01
    and l_quantity < 24; `     


-=--========= With INDEX  (idx_l_shipdatelineitem ) -=-=-====== 
Plano Execução: Aggregate  (cost=3335809.59..3335809.61 rows=1    width=16) (actual time=476033.847..476033.847 rows=1 loops=1)
 ->  Bitmap Heap Scan on lineitem  (cost=376416.20..3330284.29 rows=2210122 width=16) (actual time=375293.183..471695.391 rows=2282333 loops=1)
       Recheck Cond: ((l_shipdate >= _1995-01-01_::date) AND    (l_shipdate < _1996-01-01 00:00:00_::timestamp without time zone))
        Filter: ((l_discount >= 0.08) AND (l_discount <= 0.10) AND (l_quantity < 24::numeric))
        ->  Bitmap Index Scan on idx_l_shipdatelineitem000 (cost=0.00..375863.67 rows=17925026 width=0) (actual time=375289.456..375289.456 rows=18211743 loops=1)   
           Index Cond: ((l_shipdate >= _1995-01-01_::date) AND (l_shipdate < _1996-01-01 00:00:00_::timestamp without time zone))
Total runtime: 476034.306 ms

------------------ БЕЗ ИНДЕКСА ------------------------------ -

Plano Execucao:Aggregate  (cost=5255958.99..5255959.00 rows=1 width=16) (actual time=55051.051..55051.051 rows=1 loops=1)
  ->  Seq Scan on lineitem  (cost=0.00..5250433.68 rows=2210122 width=16) (actual time=0.394..52236.276 rows=2282333 loops=1)
        Filter: ((l_shipdate >= _1995-01-01_::date) AND (l_shipdate < _1996-01-01 00:00:00_::timestamp without time zone)
        AND (l_discount >= 0.08) AND (l_discount <= 0.10) AND (l_quantity < 24::numeric))Total runtime: 55051.380 

Из-за конкретных проблем моего исследовательского проекта я использую старую версию 9.0.1 (2012 года), потому что я использую патч, который работает только в этой версии.

Я не изменял параметры по умолчанию, только random_page_cost для 1, так как я использую диск SSD, где стоимость произвольного доступа меньше, чем стоимость жесткого диска.

Смотрите ниже содержание файла postgresql.conf

У меня вопрос, мешал ли какой-либо из этих параметров этой ошибке в статистике затрат?

max_connections = 100 
effective_io_concurrency = 5 
#seq_page_cost = 1.0                    
random_page_cost = 1.0                  
#cpu_tuple_cost = 0.01                  
#cpu_index_tuple_cost = 0.005        
#cpu_operator_cost = 0.0025             
#effective_cache_size = 128MB

[1] www.tpc.org/tpch/