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