postgresql/src/backend/optimizer/path
Tom Lane 5db2e83852 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.
2005-03-28 00:58:26 +00:00
..
Makefile $Header: -> $PostgreSQL Changes ... 2003-11-29 19:52:15 +00:00
allpaths.c Make the behavior of HAVING without GROUP BY conform to the SQL spec. 2005-03-10 23:21:26 +00:00
clausesel.c Tag appropriate files for rc3 2004-12-31 22:04:05 +00:00
costsize.c First steps towards index scans with heap access decoupled from index 2005-03-27 23:53:05 +00:00
indxpath.c Rethink the order of expression preprocessing: eval_const_expressions 2005-03-28 00:58:26 +00:00
joinpath.c The result of a FULL or RIGHT join can't be assumed to be sorted by the 2005-01-23 02:21:36 +00:00
joinrels.c Tag appropriate files for rc3 2004-12-31 22:04:05 +00:00
orindxpath.c Add a back-link from IndexOptInfo structs to their parent RelOptInfo 2005-03-27 06:29:49 +00:00
pathkeys.c Add a back-link from IndexOptInfo structs to their parent RelOptInfo 2005-03-27 06:29:49 +00:00
tidpath.c Tag appropriate files for rc3 2004-12-31 22:04:05 +00:00