pgsql: Rethink the order of expression preprocessing: - Mailing list pgsql-committers

Log Message:
-----------
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.

Modified Files:
--------------
    pgsql/src/backend/optimizer/path:
        indxpath.c (r1.171 -> r1.172)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/path/indxpath.c.diff?r1=1.171&r2=1.172)
    pgsql/src/backend/optimizer/plan:
        planner.c (r1.180 -> r1.181)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/planner.c.diff?r1=1.180&r2=1.181)
    pgsql/src/backend/optimizer/prep:
        prepqual.c (r1.48 -> r1.49)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/prep/prepqual.c.diff?r1=1.48&r2=1.49)
    pgsql/src/backend/optimizer/util:
        clauses.c (r1.189 -> r1.190)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/clauses.c.diff?r1=1.189&r2=1.190)
        restrictinfo.c (r1.31 -> r1.32)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/util/restrictinfo.c.diff?r1=1.31&r2=1.32)
    pgsql/src/backend/utils/cache:
        relcache.c (r1.216 -> r1.217)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/relcache.c.diff?r1=1.216&r2=1.217)
    pgsql/src/include/optimizer:
        prep.h (r1.48 -> r1.49)
        (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/include/optimizer/prep.h.diff?r1=1.48&r2=1.49)