Hello, Looking into the MergeAppendPath generation, I'm a bit surprised by several things:
- When generating the mergeappendpath, we use a dummy path to take the sort cost into account for non-sorted subpaths. This is called with the base relation tuples instead of the subpath estimated number of rows. This tends to overestimate the sorting cost drastically, since the base relation can be filtered thus reducing the number of input tuples for the sorting routine. Please find attached a trivial patch fixing this. - Why does it only generate a "fake" SortPath for sorting purpose, not adding it to the subpath, and posptone the creation of Sort plan node until later ? This also adds a bit of complexity when fixing the sort cost node later for explain output. - Why do we only consider generating MergeAppendPath for PathKeys for which a sorted Path exists in any of the child relation ? It seems to me there could be an advantage in using a MergeAppend of explicitly sorted relations over sorting an Append, in particular if every existing subpath can be sorted in work_mem. -- Ronan Dunklau http://dalibo.com - http://dalibo.org
diff --git a/src/backend/optimizer/util/pathnode.c b/src/backend/optimizer/util/pathnode.c index 324829690d..a99a3aeceb 100644 --- a/src/backend/optimizer/util/pathnode.c +++ b/src/backend/optimizer/util/pathnode.c @@ -1313,7 +1313,7 @@ create_merge_append_path(PlannerInfo *root, root, pathkeys, subpath->total_cost, - subpath->parent->tuples, + subpath->rows, subpath->pathtarget->width, 0.0, work_mem,
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers