From 65a7cd0e9ced21ec7ad67c11cd9a263640fe22e9 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Mon, 2 May 2011 15:56:43 -0400 Subject: Fix pull_up_sublinks' failure to handle nested pull-up opportunities. After finding an EXISTS or ANY sub-select that can be converted to a semi-join or anti-join, we should recurse into the body of the sub-select. This allows cases such as EXISTS-within-EXISTS to be optimized properly. The original coding would leave the lower sub-select as a SubLink, which is no better and often worse than what we can do with a join. Per example from Wayne Conrad. Back-patch to 8.4. There is a related issue in older versions' handling of pull_up_IN_clauses, but they're lame enough anyway about the whole area that it seems not worth the extra work to try to fix. --- src/backend/optimizer/plan/subselect.c | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'src/backend/optimizer/plan/subselect.c') diff --git a/src/backend/optimizer/plan/subselect.c b/src/backend/optimizer/plan/subselect.c index cf503d51135..30386a38091 100644 --- a/src/backend/optimizer/plan/subselect.c +++ b/src/backend/optimizer/plan/subselect.c @@ -995,6 +995,11 @@ SS_process_ctes(PlannerInfo *root) * (Notionally, we replace the SubLink with a constant TRUE, then elide the * redundant constant from the qual.) * + * On success, the caller is also responsible for recursively applying + * pull_up_sublinks processing to the rarg and quals of the returned JoinExpr. + * (On failure, there is no need to do anything, since pull_up_sublinks will + * be applied when we recursively plan the sub-select.) + * * Side effects of a successful conversion include adding the SubLink's * subselect to the query's rangetable, so that it can be referenced in * the JoinExpr's rarg. -- cgit v1.2.3