Reimplement planner's handling of MIN/MAX aggregate optimization (again).
Instead of playing cute games with pathkeys, just build a direct
representation of the intended sub-select, and feed it through
query_planner to get a Path for the index access. This is a bit slower
than 9.1's previous method, since we'll duplicate most of the overhead of
query_planner; but since the whole optimization only applies to rather
simple single-table queries, that probably won't be much of a problem in
practice. The advantage is that we get to do the right thing when there's
a partial index that needs the implicit IS NOT NULL clause to be usable.
Also, although this makes planagg.c be a bit more closely tied to the
ordering of operations in grouping_planner, we can get rid of some coupling
to lower-level parts of the planner. Per complaint from Marti Raudsepp.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/8df08c84894001d3d3f5d10b3290a1063a453316
Modified Files
--------------
src/backend/nodes/copyfuncs.c | 19 -
src/backend/nodes/equalfuncs.c | 14 -
src/backend/nodes/outfuncs.c | 5 +-
src/backend/optimizer/path/indxpath.c | 14 +-
src/backend/optimizer/path/pathkeys.c | 96 +-----
src/backend/optimizer/plan/planagg.c | 585 +++++++++++-------------------
src/backend/optimizer/plan/planmain.c | 9 -
src/backend/optimizer/plan/planner.c | 5 +-
src/include/nodes/relation.h | 8 +-
src/include/optimizer/paths.h | 16 -
src/test/regress/expected/aggregates.out | 30 +-
src/test/regress/sql/aggregates.sql | 7 +-
12 files changed, 263 insertions(+), 545 deletions(-)