Further fallout from the MergeAppend patch.
Fix things so that top-N sorting can be used in child Sort nodes of a
MergeAppend node, when there is a LIMIT and no intervening joins or
grouping. Actually doing this on the executor side isn't too bad,
but it's a bit messier to get the planner to cost it properly.
Per gripe from Robert Haas.
In passing, fix an oversight in the original top-N-sorting patch:
query_planner should not assume that a LIMIT can be used to make an
explicit sort cheaper when there will be grouping or aggregation in
between. Possibly this should be back-patched, but I'm not sure the
mistake is serious enough to be a real problem in practice.
Branch
------
master
Details
-------
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6fbc323c8042303a737028f9da7616896bccc517
Modified Files
--------------
src/backend/executor/nodeLimit.c | 57 +++++++++++++++++++++---------
src/backend/nodes/outfuncs.c | 2 +
src/backend/optimizer/plan/createplan.c | 2 +-
src/backend/optimizer/plan/planmain.c | 12 ++++++-
src/backend/optimizer/plan/planner.c | 18 +++++++++-
src/backend/optimizer/util/pathnode.c | 31 ++++++++++++++++-
src/include/nodes/relation.h | 2 +
7 files changed, 103 insertions(+), 21 deletions(-)
