diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2010-11-18 00:30:10 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2010-11-18 00:30:10 -0500 |
| commit | 6fbc323c8042303a737028f9da7616896bccc517 (patch) | |
| tree | 8335501afc6e883ea14d0f88b3ca4f48f8a759ec /src/backend/optimizer/plan/createplan.c | |
| parent | 45768d10e3abd513b4c959efeb5907798f2fac3f (diff) | |
| download | postgresql-6fbc323c8042303a737028f9da7616896bccc517.tar.gz postgresql-6fbc323c8042303a737028f9da7616896bccc517.zip | |
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.
Diffstat (limited to 'src/backend/optimizer/plan/createplan.c')
| -rw-r--r-- | src/backend/optimizer/plan/createplan.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/src/backend/optimizer/plan/createplan.c b/src/backend/optimizer/plan/createplan.c index 7a84bd91239..41ad512a296 100644 --- a/src/backend/optimizer/plan/createplan.c +++ b/src/backend/optimizer/plan/createplan.c @@ -714,7 +714,7 @@ create_merge_append_plan(PlannerInfo *root, MergeAppendPath *best_path) if (!pathkeys_contained_in(pathkeys, subpath->pathkeys)) subplan = (Plan *) make_sort(root, subplan, numsortkeys, sortColIdx, sortOperators, nullsFirst, - -1.0); + best_path->limit_tuples); subplans = lappend(subplans, subplan); } |