Re: [GENERAL] Re: Unable to understand index only scan as it is nothappening for one table while it happens for other

Поиск
Список
Период
Сортировка
От Albe Laurenz
Тема Re: [GENERAL] Re: Unable to understand index only scan as it is nothappening for one table while it happens for other
Дата
Msg-id A737B7A37273E048B164557ADEF4A58B53A5F2CF@ntex2010i.host.magwien.gv.at
обсуждение исходный текст
Ответ на [GENERAL] Re: Unable to understand index only scan as it is not happening forone table while it happens for other  (rajan <vgmonnet@gmail.com>)
Ответы [GENERAL] Re: Unable to understand index only scan as it is not happening forone table while it happens for other
Список pgsql-general
rajan wrote:
> why the index-only scan *works only* with an *order by*?
> localdb=# explain analyse verbose select uid from mm where uid>100 *order
> by* uid;
>                                                                     QUERY
> PLAN
> --------------------------------------------------------------------------------
>  Index Only Scan using mm_pkey on public.mm  (cost=0.27..22.47 rows=354 width=8)
>                                      (actual time=0.023..0.079 rows=354 loops=1)
>    Output: uid
>    Index Cond: (mm.uid > 100)
>    Heap Fetches: 0
>  Planning time: 0.096 ms
>  Execution time: 0.131 ms
> (6 rows)

I'd guess that it would work fine, but PostgreSQL chooses to use a sequential
scan instead, because too many rows meet the condition "uid > 100".

If you add the ORDER BY, the plan with the sequential scan also has to
sort the data, which makes it much more expensive, while the index only scan
returns the data in sorted order anyway and does not have to sort,
which makes it cheaper.

Yours,
Laurenz Albe

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

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: [GENERAL] Config for fast huge cascaded updates
Следующее
От: Daniel Westermann
Дата:
Сообщение: Re: [GENERAL] Which process is actually doing the WAL writes/calls XLogFlush?