我们有一个包含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';
能否请您确认这是否是创建部分索引的正确方法?会很有帮助的。
答案 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
来确定您的索引是否可以使用。