1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-05 07:21:24 +03:00

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.
This commit is contained in:
Tom Lane
2010-11-18 00:30:10 -05:00
parent 45768d10e3
commit 6fbc323c80
7 changed files with 103 additions and 21 deletions

View File

@ -694,6 +694,35 @@ create_merge_append_path(PlannerInfo *root,
pathnode->path.pathkeys = pathkeys;
pathnode->subpaths = subpaths;
/*
* Apply query-wide LIMIT if known and path is for sole base relation.
* Finding out the latter at this low level is a bit klugy.
*/
pathnode->limit_tuples = root->limit_tuples;
if (pathnode->limit_tuples >= 0)
{
Index rti;
for (rti = 1; rti < root->simple_rel_array_size; rti++)
{
RelOptInfo *brel = root->simple_rel_array[rti];
if (brel == NULL)
continue;
/* ignore RTEs that are "other rels" */
if (brel->reloptkind != RELOPT_BASEREL)
continue;
if (brel != rel)
{
/* Oops, it's a join query */
pathnode->limit_tuples = -1.0;
break;
}
}
}
/* Add up all the costs of the input paths */
input_startup_cost = 0;
input_total_cost = 0;
@ -720,7 +749,7 @@ create_merge_append_path(PlannerInfo *root,
subpath->parent->width,
0.0,
work_mem,
-1.0);
pathnode->limit_tuples);
input_startup_cost += sort_path.startup_cost;
input_total_cost += sort_path.total_cost;
}