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(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
