Question

我有一个postgresql（v9.3）查询，我有时会知道答案。我写这个：

select coalesce( <the answer>, count( distinct bar ) ) from foo;

其中＆lt;答案＆gt;实际上我不知道答案时为空。

“foo”相当大;此查询需要2秒。如果我丢弃合并并简单计数（不同的条形），结果查询需要7秒。使用pgadmin“explain”，这两个查询具有完全相同的计划。

有人可以解释发生了什么吗？如果它可以“部分”优化此查询，为什么postgres不能完全优化它？有没有办法强迫它检查＆lt;答案＆gt;在花两秒钟思考之前？

Answer 1

尝试将此查询重写为：

select coalesce( <the answer>, ( SELECT count( distinct bar ) from foo ) ) ;

如果<the answer>不为null，则根本不会评估第二个参数中的子查询。

Answer 2

Kordiko的回答满足了基本问题。为了回答对K的答案的评论中的扩展问题，结果是计数（不同）聚合是迄今为止最慢的;其他三个变得更快，并且在组合时不会变得非常慢。所以像这样的东西看起来很有希望（模数一些复合类型）：

select case when <distinct case is null> then
        ( select (<all aggregates>) from foo )
    when <some other is null> then
        ( select (<known value for distinct>, <aggregates besides distinct>) from foo)
    else
        ( select (<all known values>)) end;

postgresql部分优化查询涉及合并 - 发生了什么？

2 个答案: