Postgres没有使用索引超过一定的行数限制？

有一个测试表是这样的：Postgres没有使用索引超过一定的行数限制？

testdb=> \d test_table 
              Table "public.test_table" 
      Column   |   Type    |       Modifiers 
----------------------------+-----------------------------+----------------------------------------------------------- 
id       | integer      | not null default nextval('test_table_id_seq'::regclass) 
phone      | character varying(15)  | not null 
comment     | text      | 
timestamp     | timestamp without time zone | not null 
Indexes: 
    "test_table_pkey" PRIMARY KEY, btree (id) 
    "i_test_substr" btree ("substring"(phone::text, 1, 1), "timestamp" DESC) 
Triggers:

有了这样一个指标：

testdb=> create index i_test_substr ON test_table (substring(phone, 1, 1), timestamp desc);

这些查询将使用该索引下的203行的限制进行排序，但排序内存204行以上。

任何人都可以解释这种行为吗？

testdb=> explain analyze select * from test_table where substring(phone,1 ,1) = '2' order by timestamp desc limit 203; 
                   QUERY PLAN 
------------------------------------------------------------------------------------------------------------------------------------------- 
Limit (cost=0.42..709.52 rows=203 width=202) (actual time=0.043..0.194 rows=203 loops=1) 
    -> Index Scan using i_test_substr on test_table (cost=0.42..1146.16 rows=328 width=202) (actual time=0.041..0.170 rows=203 loops=1) 
     Index Cond: ("substring"((phone)::text, 1, 1) = '2'::text) 
Total runtime: 0.249 ms 
(4 rows) 



testdb=> explain analyze select * from test_table where substring(phone,1 ,1) = '2' order by timestamp desc limit 204; 
                   QUERY PLAN 
----------------------------------------------------------------------------------------------------------------------------------------- 
Limit (cost=711.74..712.25 rows=204 width=202) (actual time=7.655..7.681 rows=204 loops=1) 
    -> Sort (cost=711.74..712.56 rows=328 width=202) (actual time=7.653..7.664 rows=204 loops=1) 
     Sort Key: "timestamp" 
     Sort Method: top-N heapsort Memory: 53kB 
     -> Bitmap Heap Scan on test_table (cost=10.96..698.03 rows=328 width=202) (actual time=1.340..5.010 rows=11514 loops=1) 
       Recheck Cond: ("substring"((phone)::text, 1, 1) = '2'::text) 
       -> Bitmap Index Scan on i_test_substr (cost=0.00..10.88 rows=328 width=0) (actual time=1.217..1.217 rows=11514 loops=1) 
        Index Cond: ("substring"((phone)::text, 1, 1) = '2'::text) 
Total runtime: 7.746 ms 
(9 rows)

来源

2016-02-26 Ákos Vandra

请附上您的表格和查询行数的粒度没有限制+解释分析没有限制 –

'vacuum'，'analyse'，'reindex'没有帮助吗？ – devanand

这就是优化器的工作原理。请参阅Bruce Momjan关于此的幻灯片，网址为https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjCl9G05JXLAhVJDxoKHRfCAQcQFgggMAA&url=https%3A%2F%2Fmomjian.us%2Fmain ％2Fwritings％2Fpgsql％2Foptimizer.pdf＆USG = AFQjCNGDzCTCJt0n7BTrr_nqgfZIQMAUWQ＆SIG2 = k_gYi_rSo3J-SvSel1saqA – greg

简而言之，在行数太多的情况下使用索引扫描会变得非常昂贵。索引扫描会为每一行加载磁盘页面，以使它们出现在索引中。因此一些页面将被加载多次（可能多次）。位图索引扫描首先制作一系列磁盘页面，然后只加载一次。

因此，优化器计算每个可能的计划的成本，并决定哪一个是最便宜的。

来源

2016-02-26 17:55:54

Postgres没有使用索引超过一定的行数限制？

回答

相关问题