I wrote:
> 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.
Actually the executor side of it doesn't seem too bad. A Limit node
already p
Robert Haas 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
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 b
