Re: ORDER BY, LIMIT and indexes

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: ORDER BY, LIMIT and indexes
Дата
Msg-id CAGTBQpbmSsPARXhhD07_n9Zjw4O=TROORVQ0GKje8AmFkP9Oaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ORDER BY, LIMIT and indexes  (Ivan Voras <ivoras@freebsd.org>)
Список pgsql-performance
On Tue, Aug 6, 2013 at 7:46 AM, Ivan Voras <ivoras@freebsd.org> wrote:
> ivoras=# explain analyze select * from lt where id > 900000 limit 10;
>                                                    QUERY PLAN
> ----------------------------------------------------------------------------------------------------------------
>  Limit  (cost=0.00..1.71 rows=10 width=9) (actual
> time=142.669..142.680 rows=10 loops=1)
>    ->  Seq Scan on lt  (cost=0.00..17402.00 rows=101630 width=9)
> (actual time=142.665..142.672 rows=10 loops=1)
>          Filter: (id > 900000)
>  Total runtime: 142.735 ms
> (4 rows)


I think the problem lies in assuming the sequential scan will have 0
startup cost, which is not the case here (it will have to scan up to
the first page with an id > 900000).

If that were to be fixed, the index scan would be chosen instead.

I don't see a way to fix it without querying the index, which could be
a costly operation... except with the newly proposed minmax indexes. I
guess here's another case where those indexes would be useful.


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

Предыдущее
От: Ivan Voras
Дата:
Сообщение: Re: ORDER BY, LIMIT and indexes
Следующее
От: Nikolas Everett
Дата:
Сообщение: Re: ORDER BY, LIMIT and indexes