Re: [HACKERS] Solution for LIMIT cost estimation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Solution for LIMIT cost estimation
Дата
Msg-id 5419.950460829@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Solution for LIMIT cost estimation  (Chris <chris@bitmead.com>)
Ответы Re: [HACKERS] Solution for LIMIT cost estimation  (Don Baccus <dhogaza@pacifier.com>)
Список pgsql-hackers
Chris <chris@bitmead.com> writes:
> Could it _ever_ be faster to sort the tuples when there is already an
> index that can provide them in sorted order?

Yes --- in fact usually, for large tables.  Once your table gets too
big for the disk cache to be effective, indexscan performance approaches
one random-access page fetch per tuple.  Sort performance behaves more
or less as p*log(p) accesses for p pages; and a far larger proportion
of those accesses are sequential than in the indexscan case.  So the
sort will win if you have more than log(p) tuples per page.  Do the
arithmetic...

The optimizer's job would be far simpler if no-brainer rules like
"indexscan is always better" worked.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: [HACKERS] Solution for LIMIT cost estimation
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Solution for LIMIT cost estimation