涉及索引时执行计划包含错误的成本

时间:2017-08-23 06:01:17

标签: postgresql sql-execution-plan database-indexes

任何人都可以帮助我理解为什么postgresql错过了几个成本估算。

我正在进行一项来自TPCH Benchmark [1]的22个查询的实验, 检查查询中索引的性能。

在22个查询中,只验证了5个查询,即优化程序使用了二级索引。 在另一个实验中,引用的5个查询是在没有索引的情况下在数据库中执行的,以便确定执行时间是否会因缺少索引而增加。

但令我惊讶的是,数据库中没有索引的实验比使用索引更快(对于22个查询)。

我想理解,因为总费用参数在所有情况下都是错误的,即花费最多时间的所有查询都表示成本较低 - 在所有5个案例中,这在我看来是不正确的。

见下文,第一行是指您使用的查询6 指数,成本为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及其带有和不带索引的Explain Analyze。

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磁盘,随机访问的成本低于HDD的成本。

见下文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 /

0 个答案:

没有答案