问题标签 [query-planner]

这让我们感到困惑......

我们有一个使用 CAST 将浮点数转换为小数的查询，此查询连接多个表以查找要返回的行。其中一个表中的一行包含一个值，当 CAST 转换为小数时会导致算术溢出错误。

奇怪的是，具有此值的行不是结果集中返回的行之一。

过于简化的例子：

询问：

... 算术错误

如果我们在 WHERE 子句中明确排除该行，那么错误就会消失。例如。WHERE ... AND Id <> 3

.. 工作正常

有谁知道这怎么可能？

注意：这里的问题不是 CAST 在 ID 为 3 的行上失败！问题是 WHERE 子句排除了 ID 为 3 的行，但查询仍然失败。如果 WHERE 子句没有返回值为 11111.1 的行，查询如何失败？

更新 postgres 后，我注意到我正在使用的查询之一变得慢得多。运行后，EXPLAIN ANALYZE我看到它现在在同一个查询上使用不同的索引。

在其他列中，我的表有一applicationid列是外键BIGINT，我有一attributes列是jsonb键/值映射。

表中的描述coupons是（省略了一些不相关的部分）：

我正在运行的查询是（省略了一些不相关的部分）：

applicationid对我们帮助不大。之前使用的索引是coupons_attrs_index（超过attributes列），它产生了非常好的结果。

然而，在更新之后，查询规划coupons_applicationid_value_idx器出于某种原因开始偏爱索引！

这是输出EXPLAIN ANALYZE（省略了一些不相关的部分）：

谁能帮我理解为什么查询计划器在更新后使用效率较低的索引（coupons_applicationid_value_idx而不是coupons_attrs_index）？

在该索引上添加混合（BTREE + GIN）索引后(applicationid, attributes)，选择有效地解决了该问题。我仍然想了解发生了什么来预测未来这样的问题。

[编辑 31-01-20 11:02]：问题在 24 小时后返回。计划者再次选择了错误的索引，查询变得很慢。运行一个简单的analyze解决了它。还是很奇怪，更新到 PG 11 之后才开始发生。

测试表和索引（PostgreSQL 12.1）：

在第一个查询中，一切正常，使用了适当的索引“ind”：

为什么使用' ::text '类型转换'2020-02-08'（已经是文本）查询性能非常低

我使用 Amazon Aurora Postgres 10.7 在此表中有数百万条记录：

示例行：

{"id": "abc", "ts": 1580879910, "data": "my stuff"}

我有这些需要几十秒的查询：

我在这里尝试提高性能，这些都是我尝试过的所有索引，但最多我在查询计划中得到一个INDEX SCAN。

我也将查询调整为：ORDER BY (jsonData->>'ts')::integer，但没有。

最佳方案：

谁能推荐一种方法来调整索引或查询以使它们变得更快？谢谢！

对于一个小型 Postgres 10 数据仓库，我正在检查我们的分析查询的改进并发现了一个相当慢的查询，其中可能的改进基本上归结为这个子查询（经典的 best-n-per-group 问题）：

使用以下执行计划：

行估计是绝对错误的！对我来说奇怪的是，如果我现在将联接更改为右联接：

执行计划：

行估计要好得多！

我知道，例如并行顺序扫描在某些情况下会降低性能，但它们不应该改变行估计！？如果我没记错的话，聚合函数也会阻止索引的正确使用，并且也看不到任何额外的多元统计数据的潜在收益，例如 tuple id, load_dts。数据库是VACUUM ANALYZEd。

对我来说，查询在逻辑上是相同的。

有没有办法支持查询计划器对估计做出更好的假设或改进查询？也许有人知道为什么存在这种差异的原因？

编辑：以前加入条件是ON s_postings.id::text = current_postings.id::text 我将其更改ON s_postings.id = current_postings.id为不混淆任何人。删除此转换不会更改查询计划。

Edit2：如下所示，该问题有不同的解决方案greatest-n-per-group：

一个非常好的解决方案，但遗憾的是查询规划器也低估了行数：

我一直在慢慢尝试从使用 SQL 的背景中学习 MDX。在 PostgreSQL 等 DBMS 中，可以为其查询获取查询计划，例如使用EXPLAIN. 这在任何版本的 MDX 中都可能吗？如果可以，怎么做？我还没有设法遇到这种性质的东西。

我有两个这样的表：（我的实际表是不同的。我用它们来简化问题。）

当我发出这样的查询时，我得到的行估计太低了，因为查询计划器假设 item_id 和 order_id 是独立的：

我可以使用这样的查询来解决这个问题：

但是，这会导致其他效率低下，并且查询计划器对查询进行推理的灵活性较低。

另一种方法是引入连接 id 的生成列，但如果它被索引，它会增加表的空间需求，如果它是虚拟列，它将等同于先前的方法。

有没有办法告诉查询计划者如何在没有这些权衡的情况下估计一组列的基数？

查询计划显示了一个集合扫描，它遍历了 mongo 集合中的所有行。因此，我在 where 子句列上创建了一个索引，期望 Drill 选择基于索引的访问计划。但是钻继续使用全表扫描。为了让钻头使用索引，还有其他事情要做吗？

下面给出了实际查询、生成的查询计划和 mongo 索引。

SQL：

物理计划（来自钻取 UI）

在 MongoDB 中创建的索引

此外，在钻头文档中，我看到钻头仅支持 MapR DB 的索引。这是否意味着不会使用其他数据源（如 mongo）的索引？

https://drill.apache.org/docs/querying-indexes-introduction/

我正在编写一个分布式 SQL 查询计划器（查询引擎）。数据将从涉及网络 I/O 的 RDBMS(PostgreSQL) 节点获取。

我想优化 JOIN 查询。

执行的逻辑顺序是：

1. 做 JOIN（利用 ON 子句）
2. 对连接的结果应用 WHERE 子句。

我正在考虑先应用过滤器（特定于表的 WHERE 子句），然后再加入。在什么情况下会导致错误的结果？

例子：

逻辑执行：

1. joinResult = (tableA left join tableB ON() ) left join tableC ON()
2. 使用给定的 WHERE 子句过滤 joinResult。

建议执行：

1. 过滤A = tableA WHERE tableA.colY < 100

   过滤B = tableB WHERE tableB.colX > 50

2. 结果=（filteredA左连接filteredB ON（..））左连接表C ON（..）

我可以优化这样的任何查询吗？那就是先过滤表，然后在上面应用连接。

编辑：有些人在谈论这个具体的例子时感到困惑。我不是在谈论这个特定的示例查询，我正在编写一个查询计划器，我想处理所有类型的查询

请注意，每张表都被分片并存储在不同的机器上，当前的执行模型是获取每张表然后在本地进行连接。因此，如果我在获取之前应用 WHERE 过滤器，那就更好了。

我主要使用 R 包 dbplyr 与 PostgreSQL 数据库进行交互。这通过“管道”操作来工作，然后将这些操作转换为 SQL 并在一个查询中执行。这往往会导致许多嵌套连接。我想知道规划器在解决这种相当冗长和未优化的表达式时有多聪明。只要它们只使用例如 SELECT、WHERE 和 JOIN（并且没有函数、强制转换等）并且最终结果相同，是否甚至可以编写“错误查询”？这样的查询看起来如何？例如，规划器是否会计算出哈希连接中需要哪些列以减少内存，即使在该连接中没有指定列，但仅在涉及 6 个表的连接之后才指定？

例如，我可以安全地忽略：

• 加入订单
• 选择列时
• 应用过滤器时

我发现了很多关于规划器如何计算成本和选择路径的信息，但没有太多关于它如何首先到达查询的“最小形式”的信息。EXPLAIN ANALYZE 没有帮助，因为它没有显示最终选择了哪些列。我敢肯定，由于太含糊，有人会对这个问题不满意。如果是这样，请指出我正确的方向:)

编辑：

一个例子。

这是使用 dbplyr 在 R 中典型查询的外观。“gene_annotations”有“gene”和“annotation_term”列。“genemaps”有“genemap”、“gene”、“probe”、“study”。在这里，我想获取与探针相关的基因和注释。

这转化为：

我可以相信这与例如此表达式具有完全相同的性能（解析和分析表达式的时间除外）吗？

两种情况下的计划都是一样的：

我不想提供示例，因为我对这个特定查询没有任何问题。我想知道我是否总是可以完全忽略这些问题，只是拼凑连接，直到得到我想要的最终结果。

编辑2：

我发现 EXPLAIN 有一个 VERBOSE 选项，您可以在其中查看返回了哪些列。对于上面的小例子，计划在这方面也是相同的。不过，我可以假设所有合理复杂的查询都适用吗？这是我的查询通常看起来如何的示例。如您所见，dbplyr 生成的 SQL 不是很容易阅读。在这里，它在各种 SELECT/WHERE 之后连接了六个表。