database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-09-02 04:21:28 +03:00
Code Activity

Preserve AND/OR flatness while extracting restriction OR clauses.

Browse Source 
The code I added in commit f343a880d5 was
careless about preserving AND/OR flatness: it could create a structure with
an OR node directly underneath another one.  That breaks an assumption
that's fairly important for planning efficiency, not to mention triggering
various Asserts (as reported by Benjamin Smith).  Add a trifle more logic
to handle the case properly.
This commit is contained in:
Tom Lane
2014-09-09 18:35:14 -04:00
parent 07c8651dd9
commit 1b4cc493d2
3 changed files with 41 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
src/backend/optimizer/util/orclauses.c
View File

@@ -178,6 +178,7 @@ extract_or_clause(RestrictInfo *or_rinfo, RelOptInfo *rel)
{
Node *orarg = (Node *) lfirst(lc);
List *subclauses = NIL;
Node *subclause;
/* OR arguments should be ANDs or sub-RestrictInfos */
if (and_clause(orarg))
@@ -226,9 +227,16 @@ extract_or_clause(RestrictInfo *or_rinfo, RelOptInfo *rel)
/*
* OK, add subclause(s) to the result OR. If we found more than one,
* we need an AND node.
* we need an AND node. But if we found only one, and it is itself an
* OR node, add its subclauses to the result instead; this is needed
* to preserve AND/OR flatness (ie, no OR directly underneath OR).
*/
clauselist = lappend(clauselist, make_ands_explicit(subclauses));
subclause = (Node *) make_ands_explicit(subclauses);
if (or_clause(subclause))
clauselist = list_concat(clauselist,
list_copy(((BoolExpr *) subclause)->args));
else
clauselist = lappend(clauselist, subclause);
}
/*