分区表查询仍然扫描所有分区

时间:2014-02-23 05:02:35

标签: sql database postgresql partitioning

我有一张超过十亿条记录的表格。为了提高性能,我将其分区为30个分区。最常见的查询在其where子句中有(id = ...),因此我决定在id列上对表进行分区。

基本上,分区是以这种方式创建的:

CREATE TABLE foo_0 (CHECK (id % 30 = 0)) INHERITS (foo);
CREATE TABLE foo_1 (CHECK (id % 30 = 1)) INHERITS (foo);
CREATE TABLE foo_2 (CHECK (id % 30 = 2)) INHERITS (foo);
CREATE TABLE foo_3 (CHECK (id % 30 = 3)) INHERITS (foo);
.
.
.

我为整个数据库运行ANALYZE,特别是,我通过运行来收集此表的id列的额外统计信息:

ALTER TABLE foo ALTER COLUMN id SET STATISTICS 10000;

但是,当我运行在id列上过滤的查询时,计划程序会显示它仍在扫描所有分区。 constraint_exclusion设置为partition,因此不是问题。

EXPLAIN ANALYZE SELECT * FROM foo WHERE (id = 2);


                                               QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
 Result  (cost=0.00..8106617.40 rows=3620981 width=54) (actual time=30.544..215.540 rows=171477 loops=1)
   ->  Append  (cost=0.00..8106617.40 rows=3620981 width=54) (actual time=30.539..106.446 rows=171477 loops=1)
         ->  Seq Scan on foo  (cost=0.00..0.00 rows=1 width=203) (actual time=0.002..0.002 rows=0 loops=1)
               Filter: (id = 2)
         ->  Bitmap Heap Scan on foo_0 foo  (cost=3293.44..281055.75 rows=122479 width=52) (actual time=0.020..0.020 rows=0 loops=1)
               Recheck Cond: (id = 2)
               ->  Bitmap Index Scan on foo_0_idx_1  (cost=0.00..3262.82 rows=122479 width=0) (actual time=0.018..0.018 rows=0 loops=1)
                     Index Cond: (id = 2)
         ->  Bitmap Heap Scan on foo_1 foo  (cost=3312.59..274769.09 rows=122968 width=56) (actual time=0.012..0.012 rows=0 loops=1)
               Recheck Cond: (id = 2)
               ->  Bitmap Index Scan on foo_1_idx_1  (cost=0.00..3281.85 rows=122968 width=0) (actual time=0.010..0.010 rows=0 loops=1)
                     Index Cond: (id = 2)
         ->  Bitmap Heap Scan on foo_2 foo  (cost=3280.30..272541.10 rows=121903 width=56) (actual time=30.504..77.033 rows=171477 loops=1)
               Recheck Cond: (id = 2)
               ->  Bitmap Index Scan on foo_2_idx_1  (cost=0.00..3249.82 rows=121903 width=0) (actual time=29.825..29.825 rows=171477 loops=1)
                     Index Cond: (id = 2)
.
.
.

我能做些什么来使刨床有更好的计划?我是否还需要为所有分区运行ALTER TABLE foo ALTER COLUMN id SET STATISTICS 10000;

修改

在使用Erwin建议的查询更改后,计划程序只扫描正确的分区,但执行时间实际上比完整扫描(至少是索引)差。

EXPLAIN ANALYZE select * from foo where (id % 30 = 2) and (id = 2);
                                                                         QUERY PLAN
                                                                             QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Result  (cost=0.00..8106617.40 rows=3620981 width=54) (actual time=32.611..224.934 rows=171477 loops=1)
   ->  Append  (cost=0.00..8106617.40 rows=3620981 width=54) (actual time=32.606..116.565 rows=171477 loops=1)
         ->  Seq Scan on foo  (cost=0.00..0.00 rows=1 width=203) (actual time=0.002..0.002 rows=0 loops=1)
               Filter: (id = 2)
         ->  Bitmap Heap Scan on foo_0 foo  (cost=3293.44..281055.75 rows=122479 width=52) (actual time=0.046..0.046 rows=0 loops=1)
               Recheck Cond: (id = 2)
               ->  Bitmap Index Scan on foo_0_idx_1  (cost=0.00..3262.82 rows=122479 width=0) (actual time=0.044..0.044 rows=0 loops=1)
                     Index Cond: (id = 2)
         ->  Bitmap Heap Scan on foo_1 foo  (cost=3312.59..274769.09 rows=122968 width=56) (actual time=0.021..0.021 rows=0 loops=1)
               Recheck Cond: (id = 2)
               ->  Bitmap Index Scan on foo_1_idx_1  (cost=0.00..3281.85 rows=122968 width=0) (actual time=0.020..0.020 rows=0 loops=1)
                     Index Cond: (id = 2)
         ->  Bitmap Heap Scan on foo_2 foo  (cost=3280.30..272541.10 rows=121903 width=56) (actual time=32.536..86.730 rows=171477 loops=1)
               Recheck Cond: (id = 2)
               ->  Bitmap Index Scan on foo_2_idx_1  (cost=0.00..3249.82 rows=121903 width=0) (actual time=31.842..31.842 rows=171477 loops=1)
                     Index Cond: (id = 2)
         ->  Bitmap Heap Scan on foo_3 foo  (cost=3475.87..285574.05 rows=129032 width=52) (actual time=0.035..0.035 rows=0 loops=1)
               Recheck Cond: (id = 2)
               ->  Bitmap Index Scan on foo_3_idx_1  (cost=0.00..3443.61 rows=129032 width=0) (actual time=0.031..0.031 rows=0 loops=1)
.
.
.
         ->  Bitmap Heap Scan on foo_29 foo  (cost=3401.84..276569.90 rows=126245 width=56) (actual time=0.019..0.019 rows=0 loops=1)
               Recheck Cond: (id = 2)
               ->  Bitmap Index Scan on foo_29_idx_1  (cost=0.00..3370.28 rows=126245 width=0) (actual time=0.018..0.018 rows=0 loops=1)
                     Index Cond: (id = 2)
 Total runtime: 238.790 ms

对战:

EXPLAIN ANALYZE select * from foo where (id % 30 = 2) and (id = 2);
                                                                            QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Result  (cost=0.00..273120.30 rows=611 width=56) (actual time=31.519..257.051 rows=171477 loops=1)
   ->  Append  (cost=0.00..273120.30 rows=611 width=56) (actual time=31.516..153.356 rows=171477 loops=1)
         ->  Seq Scan on foo  (cost=0.00..0.00 rows=1 width=203) (actual time=0.002..0.002 rows=0 loops=1)
               Filter: ((id = 2) AND ((id % 30) = 2))
         ->  Bitmap Heap Scan on foo_2 foo  (cost=3249.97..273120.30 rows=610 width=56) (actual time=31.512..124.177 rows=171477 loops=1)
               Recheck Cond: (id = 2)
               Filter: ((id % 30) = 2)
               ->  Bitmap Index Scan on foo_2_idx_1  (cost=0.00..3249.82 rows=121903 width=0) (actual time=30.816..30.816 rows=171477 loops=1)
                     Index Cond: (id = 2)
 Total runtime: 270.384 ms

3 个答案:

答案 0 :(得分:8)

对于非平凡的表达式,您必须在查询中重复或多或少的逐字条件,以使Postgres查询规划器理解它可以依赖于CHECK约束。即使它似乎多余!

Per documentation

  

启用约束排除后,计划程序将检查   每个分区的约束并试图证明分区需要   不被扫描,因为它不能包含符合的任何行   查询的WHERE子句。 当计划者证明这一点时,它会被排除在外   查询计划中的分区。

大胆强调我的。规划者不理解复杂的表达方式。 当然,这也必须得到满足:

  

确保constraint_exclusion配置参数不是   已在postgresql.conf中停用。如果是,则不会根据需要优化查询。

而不是

SELECT * FROM foo WHERE (id = 2);

尝试:

SELECT * FROM foo WHERE id % 30 = 2 AND id = 2;

  

constraint_exclusion的默认(和推荐)设置为   实际上既不是on也不是off,而是一个叫做的中间设置   partition,这使得该技术仅应用于查询   可能在分区表上工作。开启设定   导致规划器检查所有查询中的CHECK约束,甚至   简单的,不太可能受益。

您可以尝试使用constraint_exclusion = on来查看计划程序是否在没有冗余逐字条件的情况下捕获。但是你必须权衡这种设置的成本和收益。

对于您的分区,替代方案将是更简单的条件outlined by @harmic

否,增加STATISTICS的数量在这种情况下无济于事。查询中只有CHECK个约束和WHERE条件。

答案 1 :(得分:5)

不幸的是,在postgresql中分配是相当原始的。它仅适用于基于范围和列表的约束。您的分区约束过于复杂,查询计划程序无法决定排除某些分区。

manual中说:

  

保持分区约束简单,否则规划者可能不会   能够证明不需要访问分区。使用简单   列表分区的平等条件,或简单范围测试   范围分区,如前面的例子所示。一个好的   经验法则是分区约束应该只包含   将分区列与常量进行比较   B树可索引的运算符。

正如Erwin建议的那样,你可能会改变你的WHERE子句,以便明确提到模数表达式。我过去没有太多运气,虽然我最近没有尝试,正如他所说,计划者已经有了改进。这可能是第一件尝试。

否则,您必须重新排列分区以使用id值范围,而不是现在使用的模数方法。我知道,这不是一个好的解决方案。

另一个解决方案是将id的模数存储在单独的列中,然后可以对分区约束使用简单的值相等性检查。但是,有点浪费磁盘空间,你还需要在where子句中添加一个术语来启动。

答案 2 :(得分:0)

除了Erwin关于规划器如何使用分区的细节的答案之外,还有一个更大的问题。

分区不是一个神奇的子弹。有一些非常具体的事情,分区非常有用。如果这些非常具体的事情都不适用于您,那么您不能指望通过分区提高性能,而且很可能会降低性能。

要正确进行分区,您需要彻底了解使用模式或数据加载和卸载模式。