-
- Downloads
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.
Showing
- src/backend/executor/nodeLimit.c 40 additions, 17 deletionssrc/backend/executor/nodeLimit.c
- src/backend/nodes/outfuncs.c 2 additions, 0 deletionssrc/backend/nodes/outfuncs.c
- src/backend/optimizer/plan/createplan.c 1 addition, 1 deletionsrc/backend/optimizer/plan/createplan.c
- src/backend/optimizer/plan/planmain.c 11 additions, 1 deletionsrc/backend/optimizer/plan/planmain.c
- src/backend/optimizer/plan/planner.c 17 additions, 1 deletionsrc/backend/optimizer/plan/planner.c
- src/backend/optimizer/util/pathnode.c 30 additions, 1 deletionsrc/backend/optimizer/util/pathnode.c
- src/include/nodes/relation.h 2 additions, 0 deletionssrc/include/nodes/relation.h
Loading
Please register or sign in to comment