Re: Incorrect behavior with CE and ORDER BY
От | Tom Lane |
---|---|
Тема | Re: Incorrect behavior with CE and ORDER BY |
Дата | |
Msg-id | 26540.1161747243@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Incorrect behavior with CE and ORDER BY (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Incorrect behavior with CE and ORDER BY
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.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
В списке pgsql-hackers по дате отправления: