Greenplum 数据库 - Count Distinct Queries 缓慢的问题

Question

我们正在为数据仓库使用 Greenplum OSS 版本，并在其中提供数 TB 的数据。

我们有一个特殊的问题是 Count(distinct) 查询不执行，并且执行计划是由 Postgres 查询优化器而不是 GPORCA 准备的

以下是有关问题的详细信息。 任何人都可以提供相同的帮助

基础设施背景：- 一种。 8 个数据节点的集群 湾。每个节点上 16 个 vcpu
C。每个节点上 32 GB RAM d。每个节点 8 个段 e.集群 IOPS - 读取 - ~4 GB/s

数据背景：-

1. 1.2 亿条记录的完全分布式表 - 64 个段
2. 每个 Segment 包含 – 200 万条记录

需求背景和面临的问题：-

1. 20+ 独立属性被探测为动态时间输入的不同值。 （需要注意的重点->这些属性本质上是独立的，因此不能通过group by子句将它们组合在一起，并且需要distinct）

2. Count(distinct) - 我们需要在 10 秒内的交互式查询响应来处理仪表板的这些计数。 （但获得 180+ 秒的响应时间）

我们的分析：-

1. 根据解释计划，甚至没有为这些查询调用 GPORCA，并且 Postgres 查询优化器正在准备执行计划
2. 我们尝试创建追加优化的行/列表，以尝试增加响应时间，但没有明显的改进。
3. 关闭 - “optimizer_force_multistage_agg” - 未产生任何效果。- 响应时间 - 192 秒
4. 关闭 - “enable_groupagg” - 未产生任何效果 - 响应时间 - 192 秒
5. 开启 - “enable_hashagg” - 响应时间 - 120 秒

基于以上事实，我们想知道

1. 为什么没有启用 GPORCA 优化器
2. 为什么 count(distinct) 查询花费的时间比 count(*) 查询多 15 倍。是否未使用并行化。
3. 我们如何优化这些查询。
4. 是否有其他替代方案可以满足此要求。

Answer 1

几个观察：

• 只是为了确认一下，ORCA 已在数据库范围内开启（优化器=开启）？
• 具有 16 个 vCPU 的 8 个段的 CPU 与段的比率为 2:1。 VMmware 一般建议每段 3-4 个 cpu
• 32 GB RAM 对我来说对于每个主机这么多段来说似乎有点小。

问题：

• 您是否在表上运行了 analyze 或 analyzeb（不确定是否是开源版本）以确保统计信息完全是最新的？
• 您是在 20 个属性中的 1 个上执行 select distinct，还是您正在运行 select distinct on 的多个属性的组合？如果是第一个，是否在最常用的列上建立了索引？
• 您是否尝试过对查询进行解释分析，以便准确了解问题所在？
• 这个表有多少列？

吉姆·麦肯 VMware Tanzu 数据