这是在Postgres中创建部分索引的正确方法吗?

时间:2018-10-16 03:47:24

标签: postgresql indexing postgresql-9.3 where-in partial-index

我们有一个包含400万条记录的表,对于一个特定的常用用例,我们只对特定销售人员userType为“ Standard”的记录感兴趣,而这些记录在400万中只有10,000。可能存在的其他用户类型是“ PowerPartner”,“ CSPLitePortal”,“ CustomerSuccess”,“ PowerCustomerSuccess”和“ CsnOnly”。

因此对于这个用例,我认为按照the documentation创建部分索引会更好。

因此,我计划创建此部分索引以加快对用户类型为“标准”的记录的查询,并防止来自Web的请求超时:

CREATE INDEX user_type_idx ON user_table(userType)
WHERE userType NOT IN
   ('PowerPartner', 'CSPLitePortal', 'CustomerSuccess', 'PowerCustomerSuccess', 'CsnOnly');

查找查询将为

select * from user_table where userType='Standard';

能否请您确认这是否是创建部分索引的正确方法?会很有帮助的。

2 个答案:

答案 0 :(得分:2)

Postgres可以使用它,但是这样做的效率(略)低于指定where user_type = 'Standard'的索引。

我创建了一个小型测试表,其中包含400万行,其中10.000条具有user_type 'Standard'。其他值是使用以下脚本随机分配的:

create table user_table
(
  id serial primary key,
  some_date date not null,
  user_type text not null,
  some_ts timestamp not null, 
  some_number integer not null, 
  some_data text, 
  some_flag boolean
);

insert into user_table (some_date, user_type, some_ts, some_number, some_data, some_flag)
select current_date, 
       case (random() * 4 + 1)::int
         when 1 then 'PowerPartner'
         when 2 then 'CSPLitePortal'
         when 3 then 'CustomerSuccess'
         when 4 then 'PowerCustomerSuccess'
         when 5 then 'CsnOnly'
       end, 
       clock_timestamp(),
       42, 
       rpad(md5(random()::text), (random() * 200 + 1)::int, md5(random()::text)), 
       (random() + 1)::int = 1
from generate_series(1,4e6 - 10000) as t(i)
union all 
select current_date, 
       'Standard',
       clock_timestamp(),
       42, 
       rpad(md5(random()::text), (random() * 200 + 1)::int, md5(random()::text)), 
       (random() + 1)::int = 1
from generate_series(1,10000) as t(i);

(我创建的表多于几列,因为计划者的选择还取决于表的大小和宽度)

使用带有NOT IN的索引的第一个测试:

create index ix_not_in on user_table(user_type) 
where user_type not in ('PowerPartner', 'CSPLitePortal', 'CustomerSuccess', 'PowerCustomerSuccess', 'CsnOnly');
explain (analyze true, verbose true, buffers true) 
select *
from user_table
where user_type = 'Standard'

结果:

QUERY PLAN                                                                                                                      
--------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on stuff.user_table  (cost=139.68..14631.83 rows=11598 width=139) (actual time=1.035..2.171 rows=10000 loops=1)
  Output: id, some_date, user_type, some_ts, some_number, some_data, some_flag                                                  
  Recheck Cond: (user_table.user_type = 'Standard'::text)                                                                       
  Buffers: shared hit=262                                                                                                       
  ->  Bitmap Index Scan on ix_not_in  (cost=0.00..136.79 rows=11598 width=0) (actual time=1.007..1.007 rows=10000 loops=1)      
        Index Cond: (user_table.user_type = 'Standard'::text)                                                                   
        Buffers: shared hit=40                                                                                                  
Total runtime: 2.506 ms                                                                                                         

(以上是我运行该语句约10次以消除缓存问题后的典型执行时间)

如您所见,计划者使用位图索引扫描,这是一种“有损”扫描,需要额外的步骤才能过滤掉误报。

使用以下索引时:

create index ix_standard on user_table(id) 
where user_type = 'Standard';

这将导致以下计划:

QUERY PLAN                                                                                                                              
----------------------------------------------------------------------------------------------------------------------------------------
Index Scan using ix_standard on stuff.user_table  (cost=0.29..443.16 rows=10267 width=139) (actual time=0.011..1.498 rows=10000 loops=1)
  Output: id, some_date, user_type, some_ts, some_number, some_data, some_flag                                                          
  Buffers: shared hit=313                                                                                                               
Total runtime: 1.815 ms                                                                                                                 

结论:

使用您的索引,但是仅对您感兴趣的类型建立索引会更有效。

运行时间没有太大不同。我每执行一次解释大约10次,ix_standard索引的平均值略低于2ms,而ix_not_in索引的平均值略高于2ms-因此这并不是真正的性能差异。

但是通常,索引扫描将随着表大小的增加而比位图索引扫描更好地进行缩放。这基本上是由于“重新检查条件”引起的-特别是如果没有足够的work_mem来将位图保留在内存中(对于较大的表)。

答案 1 :(得分:0)

要使用索引,必须在编写时在查询中使用WHERE条件。

PostgreSQL具有一定的推论能力,但无法推断userType = 'Standard'等同于索引中的条件。

使用EXPLAIN来确定您的索引是否可以使用。