Postgres 11 执行计划 - 在 where 子句中查询没有分区键的分区表答案

【问题标题】：Postgres 11 execution plan - Querying partitioned table without partition key in where clausePostgres 11 执行计划 - 在 where 子句中查询没有分区键的分区表
【发布时间】：2020-07-02 20:28:22
【问题描述】：

我正在尝试对大小 > 1 TB 的表 (PRT_T1) 进行分区。我选择了 2 个分区键 - entity_id_1 和 entity_id_2 以及散列分区。当两个分区键都不是 where 子句的一部分，或者假设只有一个分区键是 where 子句的一部分时，我想了解 postgres 的行为。

我检查了解释计划 -

select * 
from PRT_T1 as T1 
where T1.entity_id_1=173.

请注意，entity_id_1 和 entity_id_2 列上有索引执行计划显示首先使用 Bitmap Heap Scan 扫描所有分区，然后使用 BitMap Index scan。我附上了相同的屏幕截图。

问题是这些分区是顺序扫描还是并行扫描？

【问题讨论】：

请校对您的问题。您已将 entity_id_1 列为分区键的一部分（两次！），也列为不属于分区键的一部分。很难弄清楚你在这里真正问的是什么。

标签： postgresql database-performance database-partitioning

【解决方案1】：

除非您想在多个表空间中随机分配 I/O 负载，或者您想提高该表上的 autovacuum 性能，否则哈希分区几乎没有用处。

任何在WHERE 条件中没有带有相等运算符的完整分区键的查询都必须扫描所有分区。使用散列分区的查询不会比没有分区的查询更高效。

所有这些分区都是按顺序扫描的。如果 PostgreSQL 执行计划使用并行查询，您总是可以通过“Gather”节点的存在来判断。

【讨论】：

分配I/O是目标之一。由于遗留原因，表没有可用于范围分区的时间戳。在我的情况下，列表分区也是 NA ，因此这是唯一需要探索的选项，具体取决于分区与非分区相比的性能优势将接听电话。感谢“收集”节点信息不知道。有什么方法可以让这些分区扫描并行进行吗？
我不认为你可以。有force_parallel_mode - 你可以玩一下，看看你会得到什么。