现象描述
如下简单SQL语句查询， 性能瓶颈点在normal_date的Scan上。
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------
Seq Scan on normal_date (cost=0.00..259.00 rows=30 width=12) (actual time=0.100..3.466 rows=30 loops=1)
Filter: (("time" >= '2022-09-01 00:00:00'::timestamp without time zone) AND ("time" <= '2022-10-01 00:00:00'::timestamp without time zone))
Rows Removed by Filter: 9970
Total runtime: 3.587 ms
(4 rows)
|
优化分析
从业务层确认表数据(在time字段上)有明显的日期特征，符合分区表的特征。重新规划normal_date表的表定义：字段time为分区键、月为间隔单位定义分区表normal_date_part。修改后结果如下，性能提升近10倍。
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------
Partition Iterator (cost=0.00..480.00 rows=30 width=12) (actual time=0.038..0.085 rows=30 loops=1)
Iterations: 2
-> Partitioned Seq Scan on normal_date_part (cost=0.00..480.00 rows=30 width=12) (actual time=0.049..0.063 rows=30 loops=2)
Filter: (("time" >= '2022-09-01 00:00:00'::timestamp without time zone) AND ("time" <= '2022-10-01 00:00:00'::timestamp without time zone))
Rows Removed by Filter: 31
Selected Partitions: 3..4
Total runtime: 0.360 ms
(7 rows) |
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
