mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix oversight in 8.0 modification of RestrictInfo data structures.

Browse Source 
A RestrictInfo representing an OR clause now contains two versions of
the contained expression, one with sub-RestrictInfos and one without.
clause_selectivity() should descend to the version with sub-RestrictInfos
so that it has a chance of caching its results for the OR's sub-clauses.
Failing to do so resulted in redundant planner effort.
This commit is contained in:
Tom Lane 2005-10-11 16:44:40 +00:00
parent c6b9924bec
commit 07e6f93d6b
1 changed files with 10 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
src/backend/optimizer/path/clausesel.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/clausesel.c,v 1.73 2005/06/05 22:32:55 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/clausesel.c,v 1.74 2005/10/11 16:44:40 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -461,8 +461,15 @@ clause_selectivity(PlannerInfo *root,
}
}
/* Proceed with examination of contained clause */
clause = (Node *) rinfo->clause;
/*
* Proceed with examination of contained clause. If the clause is an
* OR-clause, we want to look at the variant with sub-RestrictInfos,
* so that per-subclause selectivities can be cached.
*/
if (rinfo->orclause)
clause = (Node *) rinfo->orclause;
else
clause = (Node *) rinfo->clause;
}
if (IsA(clause, Var))