Re: Incorrect behavior with CE and ORDER BY

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Is this possible? It would be very fast.

It's possible but not exactly simple. As an example, your proposed
plan:

> Limit (50)
> Sort (key: pse_lastlogin)
> Result
> Append
> Limit (50)
> SeqScan tbl_profile_search
> Limit (50)
> Indexscan tbl_profile_search_interest_1
> Limit (50)
> IndexScan on the index mentioned above

is wrong because there's no guarantee that the first 50 elements of a
seqscan will be anything special. You could imagine dealing with that
by sorting the seqscan results and limiting to 50, or by not
sorting/limiting that data at all but letting the upper sort see all the
seqscan entries. Offhand I think either of those could win depending on
how many elements the seqscan will yield. Also, it might be interesting
to consider inventing a "merge" plan node type that takes N
already-sorted inputs and produces a sorted output stream. Then we'd
need to trade off this approach versus doing the top-level sort, which
could cope with some of its inputs not being pre-sorted.

This seems to have some aspects in common with the recent discussion
about how to optimize min/max aggregates across an appendrel set.

regards, tom lane