8

我在 postgresql 9.2 系统上有一个查询，它的正常形式大约需要 20 秒，但使用 CTE 时只需要大约 120 毫秒。

为简洁起见，我简化了这两个查询。

这是正常形式（大约需要 20 秒）：

SELECT *
FROM tableA
WHERE (columna = 1 OR columnb = 2) AND
    atype = 35 AND
    aid IN (1, 2, 3)
ORDER BY modified_at DESC
LIMIT 25;

这是此查询的解释： http: //explain.depesz.com/s/2v8

CTE表格（约120ms）：

WITH raw AS (
    SELECT *
    FROM tableA
    WHERE (columna = 1 OR columnb = 2) AND
        atype = 35 AND
        aid IN (1, 2, 3)
)
SELECT *
FROM raw
ORDER BY modified_at DESC
LIMIT 25;

这是 CTE 的解释： http: //explain.depesz.com/s/uxy

只需将 移动ORDER BY到查询的外部即可将成本降低 99%。

我有两个问数据？

关于上述问题，是否有其他统计信息或其他规划器提示有助于提高第一个查询的性能？

编辑：取消限制也会导致查询使用堆扫描，而不是向后的索引扫描。没有LIMIT查询在 40 毫秒内完成。

在看到LIMIT我尝试使用LIMIT 1,LIMIT 2等的效果后。使用时查询在 100ms 内执行，LIMIT 1并且 10s+ LIMIT> 1。

在考虑了更多之后，问题 2 归结为为什么规划器在一种情况下使用向后索引扫描，而在另一种逻辑等效情况下使用位图堆扫描 + 排序？在这两种情况下，我如何“帮助”计划者使用有效的计划？

更新：我接受了克雷格的回答，因为它是最全面和最有帮助的。我最终解决问题的方法是使用实​​际上等效但在逻辑上不等效的查询。问题的根源在于对 modified_at 上的索引进行了索引扫描。为了通知计划者这不是一个好主意，我添加了一个谓词形式WHERE modified_at >= NOW() - INTERVAL '1 year'。这为应用程序包含了足够的数据，但阻止了规划器沿着向后索引扫描路径前进。

这是一个影响小得多的解决方案，它避免了使用子查询或 CTE 重写查询的需要。YMMV。

4

2 回答 2

10

这就是发生这种情况的原因，以下解释至少在 9.3 之前是最新的（如果您正在阅读此内容并使用较新的版本，请检查以确保它没有更改）：

PostgreSQL 不会跨 CTE 边界进行优化。每个 CTE 子句都是独立运行的，其结果由查询的其他部分使用。所以像这样的查询：

WITH blah AS (
    SELECT * FROM some_table
)
SELECT *
FROM blah
WHERE id = 4;

将导致执行完整的内部查询。PostgreSQL 不会将限定条件“下推”id = 4到内部查询中。在这方面，CTE 是“优化围栏”，有好有坏；FROM它允许您在需要时覆盖计划器，但如果您确实需要下推，则阻止您将 CTE 用作深度嵌套子查询链的简单句法清理。

如果您将上述内容改写为：

SELECT *
FROM (SELECT * FROM some_table) AS blah
WHERE id = 4;

使用子查询FROM而不是 CTE，Pg 会将 qual 下推到子查询中，它会运行得又快又好。

正如您所发现的，当查询计划者做出错误的决定时，这也可以为您带来好处。在您的情况下，表的后向索引扫描似乎要昂贵得多，位图或两个较小索引的索引扫描，然后是过滤器和排序，但规划器认为不会这样，因此它计划查询扫描索引。

当您使用 CTE 时，它无法将其推ORDER BY送到内部查询中，因此您正在覆盖它的计划并强制它使用它认为较差的执行计划 - 但事实证明它要好得多。

有一种讨厌的解决方法可以用于这些情况，称为OFFSET 0hack，但只有在您无法找到让计划者做正确事情的方法时才应该使用它 - 如果您必须使用它，请煮沸这个到一个独立的测试用例，并将其作为可能的查询计划程序错误报告给 PostgreSQL 邮件列表。

相反，我建议首先看看为什么计划者会做出错误的决定。

第一个候选是统计/估计问题，当我们查看有问题的查询计划时，果然有 3500 个对预期结果行的错误估计。这很大，但不是不可能的大，尽管更有趣的是，您实际上只获得了规划者期望的非平凡行集的一行。不过，这对我们没有多大帮助；如果行数低于预期，则意味着选择使用索引是比预期更好的选择。

主要问题看起来它没有使用更小、更有选择性的索引sierra_kilo，并且papa_lima因为它看到ORDER BY并认为它会节省更多的时间来执行反向索引扫描并避免排序而不是实际执行。这是有道理的，因为只有一个匹配的行要排序！如果它获得了预期的 3500 行，那么避免排序可能更有意义，尽管这仍然是一个相当小的行集，仅用于在内存中排序。

您是否设置了任何参数enable_seqscan，例如等？如果这样做，请取消设置它们；它们仅用于测试，完全不适合生产使用。如果您不使用这些enable_参数，我认为值得在 PostgreSQL 邮件列表中提出这一点pgsql-perform。但是，匿名计划使这有点困难，特别是因为无法保证一个计划中的标识符引用另一个计划中的相同对象，并且它们与您在问题查询中写的内容不匹配。您需要制作一个正确的手工版本，在邮件列表中询问之前所有内容都匹配。

您很有可能需要为任何人提供真正的价值来提供帮助。如果您不想在公共邮件列表中这样做，还有另一个选项可用。（我应该注意，根据我的个人资料，我为其中一个工作）。

于 2013-07-11T01:43:34.033 回答
2

只是在黑暗中拍摄，但如果你运行它会发生什么

SELECT *
FROM (
    SELECT *
    FROM tableA
    WHERE (columna = 1 OR columnb = 2) AND
        atype = 35 AND
        aid IN (1, 2, 3)
) AS x
ORDER BY modified_at DESC
LIMIT 25;
于 2013-07-11T01:35:55.203 回答