列上的索引速度很慢,不是唯一的吗?

时间:2014-10-22 06:57:01

标签: postgresql

列上的索引速度很慢,不是唯一的吗?有一个代码和日期列的索引,但它不是唯一的。平均需要5分钟才能获得数据。怎么改进呢?

EXPLAIN ANALYZE select * from timestockdata where code ='3182' and date>'2014-02-04'
"Bitmap Heap Scan on timestockdata  (cost=3300.94..359202.76 rows=106234 width=439) (actual time=734.561..86351.988 rows=127715 loops=1)"
"  Recheck Cond: (((code)::text = '3182'::text) AND (date > '2014-02-04 00:00:00'::timestamp without time zone))"
"  Rows Removed by Index Recheck: 2689023"
"  ->  Bitmap Index Scan on timestockdata_index  (cost=0.00..3274.38 rows=106234 width=0) (actual time=713.362..713.362 rows=127715 loops=1)"
"        Index Cond: (((code)::text = '3182'::text) AND (date > '2014-02-04 00:00:00'::timestamp without time zone))"
"Total runtime: 86476.266 ms"

http://explain.depesz.com/s/AnxT

CREATE INDEX timestockdata_index
  ON timestockdata
  USING btree
  (code COLLATE pg_catalog."default", date);

将工作mem设置为100mb。

"Bitmap Heap Scan on timestockdata  (cost=3304.95..359206.77 rows=106234 width=439) (actual time=2653.288..933680.348 rows=127902 loops=1)"
"  Recheck Cond: (((code)::text = '3182'::text) AND (date > '2014-02-04 00:00:00'::timestamp without time zone))"
"  Buffers: shared hit=58 read=118695 written=37"
"  I/O Timings: read=931565.063 write=0.663"
"  ->  Bitmap Index Scan on timestockdata_index  (cost=0.00..3278.39 rows=106234 width=0) (actual time=2582.697..2582.697 rows=127902 loops=1)"
"        Index Cond: (((code)::text = '3182'::text) AND (date > '2014-02-04 00:00:00'::timestamp without time zone))"
"        Buffers: shared hit=2 read=1465"
"        I/O Timings: read=2399.675"
"Total runtime: 933817.470 ms"

result = 58117248

select count(*) from timestockdata

我有其他交易明细表,共有73569274条记录。这个数据比以前的timestockdata表大得多,但可以在11秒内解决。我认为唯一不同的是因为timestockdata以非订单格式保存(save-> code1,date.save-> code2,date),其中tradedetail表以订单格式保存(save-> code1,整个日期)那天只转移到code2进行全天交易。)

EXPLAIN (ANALYZE,buffers) select * from tradedetail where code='3182' and  date::date <'2014-02-04' order by date
"Sort  (cost=887351.99..888022.69 rows=268280 width=47) (actual time=11203.296..11237.917 rows=348740 loops=1)"
"  Sort Key: date"
"  Sort Method: external sort  Disk: 22496kB"
"  Buffers: shared hit=1 read=14085, temp read=2812 written=2812"
"  ->  Bitmap Heap Scan on tradedetail  (cost=30586.27..846656.01 rows=268280 width=47) (actual time=7070.147..10756.227 rows=348740 loops=1)"
"        Recheck Cond: ((code)::text = '3182'::text)"
"        Filter: ((date)::date < '2014-02-04'::date)"
"        Rows Removed by Filter: 412035"
"        Buffers: shared hit=1 read=14085"
"        ->  Bitmap Index Scan on tradedetail_index  (cost=0.00..30519.20 rows=804841 width=0) (actual time=7048.439..7048.439 rows=769686 loops=1)"
"              Index Cond: ((code)::text = '3182'::text)"
"              Buffers: shared hit=1 read=5766"
"Total runtime: 11265.853 ms"

1 个答案:

答案 0 :(得分:0)

如果您实际上不需要检索125,000行,请重写查询,以便它不会返回那么多行。

您的位图堆扫描看起来像是溢出,需要昂贵的重新检查。你可以考虑增加work_mem来帮助它。

您可以根据该索引对表进行聚类,以使具有相同code的行在物理上相邻。

您可能会从更多RAM和/或更快的磁盘阵列中受益。

此外,EXPLAIN (ANALYZE,buffers)会提供更多有用的信息,特别是如果启用了track_io_timing。