Rethink the order of expression preprocessing: eval_const_expressions
Tom Lane <tgl@sss.pgh.pa.us>
Rethink the order of expression preprocessing: eval_const_expressions really ought to run before canonicalize_qual, because it can now produce forms that canonicalize_qual knows how to improve (eg, NOT clauses). Also, because eval_const_expressions already knows about flattening nested ANDs and ORs into N-argument form, the initial flatten_andors pass in canonicalize_qual is now completely redundant and can be removed. This doesn't save a whole lot of code, but the time and palloc traffic eliminated is a useful gain on large expression trees.
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/optimizer/path/indxpath.c | modified | +3 −3 |
| src/backend/optimizer/plan/planner.c | modified | +11 −12 |
| src/backend/optimizer/prep/prepqual.c | modified | +24 −103 |
| src/backend/optimizer/util/clauses.c | modified | +6 −3 |
| src/backend/optimizer/util/restrictinfo.c | modified | +2 −2 |
| src/backend/utils/cache/relcache.c | modified | +14 −15 |
| src/include/optimizer/prep.h | modified | +1 −2 |