Avoid reversing user-given order of WHERE clauses while attaching clauses

to specific base or join RelOptInfo nodes during planning.  This preserves
the more-intuitive behavior of 7.0.* --- if you write an expensive clause
(such as a sub-select) last, it should get evaluated last.  Someday we
ought to try to have some intelligence about the order of evaluation of
WHERE clauses, but for now we should not override what the user wrote.
This commit is contained in:
Tom Lane 2001-04-16 19:44:10 +00:00
parent 722f7efdd9
commit cdcaec5c53

View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/initsplan.c,v 1.58 2001/03/22 03:59:36 momjian Exp $
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/initsplan.c,v 1.59 2001/04/16 19:44:10 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -444,8 +444,8 @@ distribute_qual_to_rels(Query *root, Node *clause,
*/
RelOptInfo *rel = get_base_rel(root, lfirsti(relids));
rel->baserestrictinfo = lcons(restrictinfo,
rel->baserestrictinfo);
rel->baserestrictinfo = lappend(rel->baserestrictinfo,
restrictinfo);
/*
* Check for a "mergejoinable" clause even though it's not a join
@ -549,8 +549,8 @@ add_join_info_to_rels(Query *root, RestrictInfo *restrictinfo,
*/
joininfo = find_joininfo_node(get_base_rel(root, cur_relid),
unjoined_relids);
joininfo->jinfo_restrictinfo = lcons(restrictinfo,
joininfo->jinfo_restrictinfo);
joininfo->jinfo_restrictinfo = lappend(joininfo->jinfo_restrictinfo,
restrictinfo);
}
}