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