Re: MergeAppend costing

Robert Haas <robertmhaas@gmail.com> writes:
> See the attached test case.  With that setup, this uses MergeAppend:
> explain select * from ma_parent order by id limit 10;

> But this one does not:

> explain select * from ma_parent order by name limit 10;

> ...which seems odd, because the index on ma_child1 and sorting the
> other two ought to still be better than appending all three and
> sorting the whole thing.

Not really; what you're not accounting for is that the top-level sort
is a lot cheaper than a full sort of the large child relation would be,
because it gets hacked to do a top-N sort instead of a full sort.

What this example suggests is that we should consider ways to pass
down the top-N-ness to sorts executed as part of a MergeAppend tree.
That seems a tad messy though, both in the executor and the planner.
        regards, tom lane