Performance 博士后的表现真的很慢
我有一个表，我只插入行，从不删除。 在每个循环上，我插入大约36k行 我需要从此表中获取行以执行操作。 问题是每个循环的查询性能都非常差 例如，在循环31上：Performance 博士后的表现真的很慢,performance,postgresql,bitmap,indexing,Performance,Postgresql,Bitmap,Indexing,我有一个表，我只插入行，从不删除。 在每个循环上，我插入大约36k行 我需要从此表中获取行以执行操作。 问题是每个循环的查询性能都非常差 例如，在循环31上： explain analyze select exp(least(709,a.value)), a.from, a.to,a.material,a.transport from resultTable a where a.loop=31;
explain analyze select exp(least(709,a.value)), a.from, a.to,a.material,a.transport from resultTable a where a.loop=31;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on resultTable a (cost=36.58..4431.79 rows=2425 width=48) (actual time=7.351..33894.217 rows=34640 loops=1)
Recheck Cond: (loop = 31)
-> Bitmap Index Scan on "resultTable_idx_mo" (cost=0.00..35.97 rows=2425 width=0) (actual time=4.880..4.880 rows=34640 loops=1)
Index Cond: (loop = 31)
Total runtime: 33897.070 ms
(5 rows)
explain analyze select exp(least(709,a.value)), a.from, a.to,a.material,a.transport from resultTable a where a.loop=43;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Bitmap Heap Scan on resultTable a (cost=36.58..4431.79 rows=2425 width=48) (actual time=10.129..125460.445 rows=34640 loops=1)
Recheck Cond: (loop = 43)
-> Bitmap Index Scan on "resultTable_idx_mo" (cost=0.00..35.97 rows=2425 width=0) (actual time=4.618..4.618 rows=34640 loops=1)
Index Cond: (loop 43)
Total runtime: 125463.516 ms
(5 rows)
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Result (cost=14.47..2686.29 rows=1649 width=48) (actual time=18.562..220124.597 rows=34640 loops=1)
-> Append (cost=14.47..2682.17 rows=1649 width=48) (actual time=5.189..32.743 rows=34640 loops=1)
-> Bitmap Heap Scan on resultTable a (cost=14.47..1655.44 rows=866 width=48) (actual time=0.008..0.008 rows=0 loops=1)
Recheck Cond: (loop = 60)
-> Bitmap Index Scan on "resultTable_idx_mo" (cost=0.00..14.26 rows=866 width=0) (actual time=0.006..0.006 rows=0 loops=1)
Index Cond: (loop = 60)
-> Bitmap Heap Scan on result_table_child_70 a (cost=8.82..1026.73 rows=783 width=48) (actual time=5.181..29.068 rows=34640 loops=1)
Recheck Cond: (loop = 60)
-> Bitmap Index Scan on resultTable_child_70_idx (cost=0.00..8.63 rows=783 width=0) (actual time=4.843..4.843 rows=34640 loops=1)
Index Cond: (loop = 60)
Total runtime: 220128.290 ms
Result (cost=0.00..2761.06 rows=33652 width=389) (actual time=9.714..378389.177 rows=34640 loops=1)
-> Append (cost=0.00..2676.93 rows=33652 width=389) (actual time=0.119..34.065 rows=34640 loops=1)
-> Index Scan using "resultTable_idx_mo" on resultTable a (cost=0.00..12.84 rows=5 width=48) (actual time=0.058..0.058 rows=0 loops=1)
Index Cond: (loop= 79)
-> Index Scan using resultTable_child_80_idx on resultTable_child_80 a (cost=0.00..2664.10 rows=33647 width=389) (actual time=0.061..30.303 rows=34640 loops=1)
Index Cond: (loop = 79)
Total runtime: 378393.671 ms
(7 rows)
群集可能会加快速度：
cluster resultTable using resultTable_idx_mo;
群集可能会加快速度：
cluster resultTable using resultTable_idx_mo;
如果群集和分区不起作用，我开始怀疑您的存储系统存在严重问题。10秒的堆扫描35K行速度太慢了几个数量级。你使用的是什么版本的Postgres？您的存储看起来像什么？检查你的iostats 我在一个小型VM（1个分数cpu，1GB内存，NFS磁盘挂载）上做了一个实验，Pg 9.0.4制作了表和索引，并注入了1000批36000条记录
insert into r(loop,value,xfrom,xto,material,transport,pk) select 0,0,0,0,0,0,i from generate_series(0,35999) i;
insert into r(loop,value,xfrom,xto,material,transport,pk) select 1,0,0,0,0,0,i from generate_series(36000,71999) i;
...
explain analyze select exp(least(709,a.value)), a.xfrom, a.xto, a.material,a.transport from r a where a.loop=31;
Index Scan using "resultTable_idx_mo" on r a (cost=0.00..1596.35 rows=37680 width=21) (actual time=0.087..34.038 rows=36000 loops=1)
Index Cond: (loop = 31)
Total runtime: 36.332 ms
explain analyze select exp(least(709,a.value)), a.xfrom, a.xto,a.material,a.transport from r a where a.loop=87;
Index Scan using "resultTable_idx_mo" on r a (cost=0.00..1421.35 rows=33480 width=21) (actual time=0.105..37.357 rows=36000 loops=1)
Index Cond: (loop = 87)
Total runtime: 39.365 ms
anaylizeresultatable
我相信，当这些简单的索引扫描选择花费几十毫秒以上时，您的postgres配置或存储系统中会出现严重损坏。当您运行查询时，此数据库上是否还有其他活动？也许您的结果与其他查询竞争资源？如果群集和分区不起作用，我开始怀疑您的存储系统存在严重问题。10秒的堆扫描35K行速度太慢了几个数量级。你使用的是什么版本的Postgres？您的存储看起来像什么？检查你的iostats
我在一个小型VM（1个分数cpu，1GB内存，NFS磁盘挂载）上做了一个实验，Pg 9.0.4制作了表和索引，并注入了1000批36000条记录
insert into r(loop,value,xfrom,xto,material,transport,pk) select 0,0,0,0,0,0,i from generate_series(0,35999) i;
insert into r(loop,value,xfrom,xto,material,transport,pk) select 1,0,0,0,0,0,i from generate_series(36000,71999) i;
...
在任何批次上运行select始终低于40ms：
explain analyze select exp(least(709,a.value)), a.xfrom, a.xto, a.material,a.transport from r a where a.loop=31;
Index Scan using "resultTable_idx_mo" on r a (cost=0.00..1596.35 rows=37680 width=21) (actual time=0.087..34.038 rows=36000 loops=1)
Index Cond: (loop = 31)
Total runtime: 36.332 ms
explain analyze select exp(least(709,a.value)), a.xfrom, a.xto,a.material,a.transport from r a where a.loop=87;
Index Scan using "resultTable_idx_mo" on r a (cost=0.00..1421.35 rows=33480 width=21) (actual time=0.105..37.357 rows=36000 loops=1)
Index Cond: (loop = 87)
Total runtime: 39.365 ms
注意，我的计划提出了普通索引扫描，而不是紧跟着堆扫描的位图扫描。您是否调整了计划优化配置以影响计划
在您的解释中，我注意到估计的行数远小于实际的行数（1649对34640）。这表明表中的统计数据不准确。您应该运行anaylizeresultatable
我相信，当这些简单的索引扫描选择花费几十毫秒以上时，您的postgres配置或存储系统中会出现严重损坏。当您运行查询时，此数据库上是否还有其他活动？也许您的结果与其他查询竞争资源？您是否在集群
后发出分析
？@barboso在分区后显示解释。您是否在集群
后发出分析
？@barboso在分区后显示解释。如果您在同一个集群上运行解释分析连续两次循环值运行时是否有显著改进？36K*48字节的行宽约为2MB。一旦pg读取了所有数据块，这些数据块应该很容易适应并保留在任何大小合理的系统上的OS页面缓存中，因此在第二次运行时，堆扫描应该在没有IO的情况下完全从内存中收集行。您的系统有多少内存？如果您连续两次对同一循环值运行解释分析，运行时是否会显著提高？36K*48字节的行宽约为2MB。一旦pg读取了所有数据块，这些数据块应该很容易适应并保留在任何大小合理的系统上的OS页面缓存中，因此在第二次运行时，堆扫描应该在没有IO的情况下完全从内存中收集行。你的系统有多少内存？