问题标签 [query-planner]

我没有看到这个实现中的错误：

这是某种 PostgreSQL 错误还是对anyelement数据类型的未记录限制？

有趣的是：当被隔离时，CASE子句可以正常工作：

我有一个非常简单的表，其中包含 2 列 message_id 和 server_timestamp，但是当我查看此查询的计划时：

其中 index_messages_id_server_timestamp 是 (message_id, server_timestamp) 上的索引。

为什么这个查询需要使用临时 b 树进行排序？

HAWQ 中的查询计划可以拆分为多个可以独立运行的切片。HAWQ 如何将查询计划拆分为切片？

我面临一个奇怪的问题。当我正在开发我的应用程序的新功能时，我创建了生产数据库的转储，将它们加载到我的开发环境中。如果我尝试在开发和生产中运行相同的查询，我会得到 2 个不同的计划，返回非常不同的查询时间：

查询如下：

它在开发中启动时生成以下计划：

总运行时间始终低于 500 毫秒，而它计划这样做：

在生产中运行时间超过 1.5 秒。请考虑生产数据库是定期清理的（我刚刚对真空进行了详细分析；同样，但没有任何改变）。

我认为首先出错的是成本估算（生产中的 149898.67 与开发中的 41835.73）。我如何改进生产中的规划器？

先感谢您！

阿尔贝托

更新 here你可以找到2个postgres.conf之间的差异。请考虑发现的所有差异都已注释，因此我认为两个 pg 都使用默认值（我认为它们是注释的值。还请注意 dev 正在运行 v9.5.3 而 prod 正在运行 v9.3.4

谢谢大家。我在将数据库从 MySQL 5.5 升级到 5.7 时遇到了一个问题，这让我完全困惑。升级不是使用 mysqldump 或类似工具完成的，而是使用几个非常长的 SQL 脚本从几个制表符分隔的输入文件重建。特别是一个看似无害的查询（在存储过程中）一直给我带来麻烦，我不知道为什么：

这看起来相当简单，但是这个查询的 EXPLAIN 表明正在进行一些严重的行扫描：

重要的似乎是行列，对于 UPDATE 是 1198100，对于 SELECT 子查询是 1200537。这两个数字都非常接近两个引用表中的总行数（两者均为 1207744）。所以它似乎对两者的行扫描都进行了整行，我不明白为什么。完全相同的查询在 MySQL 5.5 中运行良好。我希望这个解决方案会有所帮助，但是将 'derived_merge=off' 传递给了 optimizer_switch 并且重新启动服务器并没有帮助。

我当然不希望这个查询超级快。它不一定是。之前的速度并不快（在 7200rpm 旋转磁盘上几分钟），但自从升级到 MySQL 5.7 之后，它似乎在宇宙热死之前的任何时候都不会完成，我宁愿不等长。有没有人有任何想法？无论是查询重写，还是 my.ini 设置或其他任何东西？

另外，如果我以任何方式违反协议或者我是否可以改进我的问题，请告诉我。正如我上面所说，这是我在这里的第一篇文章。

感谢您的时间。

编辑：我想了一会儿，这个解决方案看起来很有希望。显然，具有不同字符集/排序规则的表无法正确读取彼此的索引。我很确定一切都在latin1，但认为值得确定。所以我明确地添加DEFAULT CHARSET=latin1到我的所有CREATE TABLE陈述中并添加CHARACTER SET latin1到我的LOAD DATA INFILE陈述中。可悲的是，没有改变。

我的规划器 postgresql 有问题我有一个包含多个分区的表，然后添加了相当数量的后续分区。主表上的 EXPLAIN 不显示新分区。对主表执行 SELECT 不会看到添加到新分区的记录，对新分区执行 SELECT 会看到记录

例如：

• 表（id、零件号、数据）
• Tabela_part1（检查零件号 = 1）
• Tabela_part2（检查零件编号 = 2）

...

• Tabela_part10（检查零件编号 = 10）

添加新分区后

• 表（id、零件号、数据）
• Tabela_part1（检查零件号 = 1）
• Tabela_part2（检查零件编号 = 2）

...

• Tabela_part100（检查部件号 = 100）

新分区 Tab​​le_part11 的 DDL 示例：

创建表 Table_part11 ( CONSTRAINT table_part11_pkey PRIMARY KEY (id), CHECK (partnumber = 11) ) 继承 (Table)';

后

SELECT * FROM Tabela_part11 WHERE id = 1234- 它显示了记录。

SELECT * FROM Table WHERE id = 1234- 它不显示记录

我试过了

• 抽真空/分析主表和分区
• 为主表和分区上的索引重新索引索引

请帮忙

更新 11/2

12c在进行了一些额外的故障排除后，我的团队能够将这个 Oracle 错误直接与查询停止工作前一天晚上对数据库进行的参数更改联系起来。在遇到与该数据库相关的应用程序的一些性能问题后，我的团队让我们的 DBA 将OPTIMIZER_FEATURES_ENABLE参数从更改12.1.02为11.2.0.4. 这解决了问题应用程序的性能问题，但导致了我上面描述的错误。为了验证，我已经能够通过更改此参数在单独的环境中复制同样的问题。我的 DBA 已向 Oracle 提交了一张票，以查看此问题。

作为一种解决方法，我可以对查询进行轻微更改以检索预期结果。具体来说，我结合Subquery1并Subquery2把一些谓词Subquery1从WHERE子句移到了JOIN（它们更合适的地方）。此更改编辑了我的执行计划（它的效率略低于之前列出的内容），但足以解决最初的问题。

原帖

首先，让我为这个问题的任何含糊之处道歉，但我正在处理一个机密的金融系统，所以我不得不隐藏某些实施细节。

背景

我有一个Oracle很久以前投入生产的查询，最近在升级11g到12c. 据我（和我的生产支持团队）所知，此查询在此之前已经运行了一年多。

细节

查询过于复杂且效率不高，但这在很大程度上是因为我正在处理非规范化表（历史上以大型机建模）和来自上游系统的不良数据输入。为了处理复杂的业务情况，我利用了多个级别的子查询因子（WITH语句），然后我的最终语句将两个内联视图连接在一起。没有所有复杂谓词的查询的基本结构如下：

我有 3 张桌子Table1, Table2, Table3. Table1是一个处理表，由来自 的记录组成Table2。

最后的查询非常基本：

问题

如果我编辑最终查询以删除第二个内联视图并评估A内联视图的输出，我会得到0 个返回的行。我已经手动评估了每个单独子查询的记录，并且可以确认这是预期结果。

同样，如果我编辑最终查询以仅生成“B”内联视图的输出，我会得到6 个返回的行。同样，我手动评估了数据，这完全符合预期。

现在，当将这两个子集（内联视图A和内联视图B）连接在一起时，我希望最终查询结果为 0 行（因为完整集和空集之间的内部连接不会产生匹配项）。但是，当我如上所述使用内部连接运行整个查询时，我得到了 1158 行！

我已经查看了执行计划，但没有任何问题：

问题

显然，我做了一些事情来混淆 Oracle 优化器，并且更新的查询计划正在撤回与我提交的查询完全不同的查询。我最好的猜测是，所有这些临时视图都在同一个查询中浮动，我混淆了 Oracle 以评估它所依赖的某个集合之前的某些集合。

直到今天，我一直无法在WITH声明周围找到官方的 Oracle 文档，因此我对评估子查询的顺序从未完全有信心。我在搜索 SO（现在找不到）时确实注意到有人提到因子子查询不能引用另一个因子查询。我以前从不知道这是真的，但上面奇怪的输出让我想知道我之前是否只是幸运地使用了这个查询？

谁能解释我看到的行为？我是否试图用这个查询计划做一些明显不正确的事情？或者，是否有可能在 11g 和 12c 之间发生了一些变化，这可以解释为什么这个查询的行为可能已经改变了？

我想知道为什么我的实际行数大于估计的行数？

该表有一个聚集的主键，定义为：

虽然我也更新了MeasurementDateTime列和重建索引的统计信息。

问题：

• 为什么实际行数大于估计行数？它对性能有什么影响吗？

• 我是否应该始终尝试使实际行数等于估计的行数？或者实际和估计的行数有多少变化不应该打扰我们？

我有一个带有三列表（大约 150 000 行）的 postgres 数据库；row_id、位置和计数的花朵数。由于位置彼此相当接近，因此计数可能存在一些错误，我想知道每个位置的平均计数，所以我写了以下 sql 问题：

哪个有效，并给我前 100 分的平均计数，大约需要 15 秒。当我将限制增加到 1000 时，运行时间增加到大约 1.5 分钟，依此类推。因此，我想在不到 30 秒的时间内为所有 150 000 行运行问题。有什么建议么？row_id 上有一个 btree 索引，pos 上有一个 gist_index。

我添加了查询计划：

我已经修补/阅读了一段时间，但找不到任何可以在这里工作的优化......我已经在连接中索引了相关的 id，我尝试了手动真空，我还尝试在索引上进行聚类所以由于一些分散的行，查询优化器可能不会认为扫描整个表更有效（尽管我对查询计划知之甚少）。

我正在尝试获取单个 id 的连接结果（用于调试目的）。我发现查询某些单个 id 大约需要 2 分钟，而大多数（99%？）会在 1 秒内返回。这里有一些explain analyzes（为了保密，我用sed改了一些名字）：

我还要补充一点，对于长时间运行的查询，即使 2 分钟后仅返回 250 行，添加“LIMIT 100”也可以使查询立即返回。我调查了速度是否与查询返回的数据量有关，我没有看到任何明显的趋势。我不禁觉得 Postgres 完全错误（100 倍？）关于它的哪种方法会更快。我在这里有什么选择？