Re: Avoiding a seq scan on a table.

Поиск
Список
Период
Сортировка
От Brian Hurt
Тема Re: Avoiding a seq scan on a table.
Дата
Msg-id 478B9BA9.3060504@janestcapital.com
обсуждение исходный текст
Ответ на Re: Avoiding a seq scan on a table.  (LWATCDR <lwatcdr@gmail.com>)
Список pgsql-novice
LWATCDR wrote:

>Really? From what I have done in writing my own code I have found
>hashing to be faster than a btree but then when I wrote my own hashing
>it was a specific type of key.
>Anyway I put in the tree indexes and I am still getting a seq scan.
>
>Aggregate  (cost=12.12..12.13 rows=1 width=0)
>  ->  Result  (cost=0.00..12.12 rows=1 width=0)
>        One-Time Filter: NULL::boolean
>        ->  Seq Scan on issuetracking  (cost=0.00..12.12 rows=1 width=0)
>              Filter: (((issue_target)::text = 'david'::text) OR
>((manager)::text = 'david'::text))
>
>
>
>
For very small tables, Postgres will skip reading the indexes, because
it's not worth it.  Postgres thinks it's only going to have to read 12
pages or so.  At which point it'll likely have to read all the pages
anyways, so why also read the index?

Brian


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

Предыдущее
От: Alan Hodgson
Дата:
Сообщение: Re: Avoiding a seq scan on a table.
Следующее
От: LWATCDR
Дата:
Сообщение: Re: Avoiding a seq scan on a table.