Re: Avoiding a seq scan on a table.

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