Prevent planagg.c from failing on queries containing CTEs.

The existing tests in preprocess_minmax_aggregates() usually prevent it
from trying to do anything with queries containing CTEs, but there's an
exception: a CTE could be present as a member of an appendrel, if we
flattened a UNION ALL that contains CTE references.  If it did try to
generate an optimized path for a query using a CTE, it failed with
"could not find plan for CTE", as reported by Torsten Förtsch.

The proximate cause is an unwise decision in commit 3fc6e2d7f to clear
subroot->cte_plan_ids in build_minmax_path().  That left the subroot's
cte_plan_ids list out of step with its parse->cteList.

Removing the "subroot->cte_plan_ids = NIL;" assignment is enough to let
the case work again, but really it's pretty silly to be expending any
cycles at all in this module when there are CTEs: we always treat their
outputs as unordered so there's no way for the optimization to win.
Hence, also add an early-exit test so we don't waste time like that.

Back-patch to 9.6 where the misbehavior was introduced.

Report: https://postgr.es/m/CAKkG4_=gjY5QiHtqSZyWMwDuTd_CftKoTaCqxjJ7uUz1-Gw=qw@mail.gmail.com

diff --git a/src/backend/optimizer/plan/planagg.c b/src/backend/optimizer/plan/planagg.c
index 805aae7ee7a79b3486b74bbe1f866fc112c7a617..4216fc4a6ea807dbd297b5359cbd7cc5b2943d5f 100644 (file)
--- a/src/backend/optimizer/plan/planagg.c
+++ b/src/backend/optimizer/plan/planagg.c
@@ -103,6 +103,14 @@ preprocess_minmax_aggregates(PlannerInfo *root, List *tlist)
                parse->hasWindowFuncs)
                return;
 
+       /*
+        * Reject if query contains any CTEs; there's no way to build an indexscan
+        * on one so we couldn't succeed here.  (If the CTEs are unreferenced,
+        * that's not true, but it doesn't seem worth expending cycles to check.)
+        */
+       if (parse->cteList)
+               return;
+
        /*
         * We also restrict the query to reference exactly one table, since join
         * conditions can't be handled reasonably.  (We could perhaps handle a
@@ -360,7 +368,6 @@ build_minmax_path(PlannerInfo *root, MinMaxAggInfo *mminfo,
        subroot->plan_params = NIL;
        subroot->outer_params = NULL;
        subroot->init_plans = NIL;
-       subroot->cte_plan_ids = NIL;
 
        subroot->parse = parse = (Query *) copyObject(root->parse);
        IncrementVarSublevelsUp((Node *) parse, 1, 1);