Re: MergeAppend costing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: MergeAppend costing
Date
Msg-id 26347.1290035475@sss.pgh.pa.us
Whole thread Raw
In response to MergeAppend costing  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: MergeAppend costing
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: We need to log aborted autovacuums
Next
From: Josh Berkus
Date:
Subject: Re: We need to log aborted autovacuums