postgresql - 在不使用 CTE 的情况下，是否有此查询的逻辑等效且有效的版本？

Question

我在 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等。使用 LIMIT 1 时，查询在 100 毫秒内执行。和 10s+ 与 LIMIT > 1。

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

您很有可能需要为任何人提供真正的值(value)来提供帮助。如果您不想在公共(public)邮件列表中这样做， there's another option available . (我应该注意，根据我的个人资料，我为其中一个工作)。