Re: Avoiding a seq scan on a table. - Mailing list pgsql-novice

From Brian Hurt
Subject Re: Avoiding a seq scan on a table.
Date
Msg-id 478B9BA9.3060504@janestcapital.com
Whole thread Raw
In response to Re: Avoiding a seq scan on a table.  (LWATCDR <lwatcdr@gmail.com>)
List 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 by date:

Previous
From: Alan Hodgson
Date:
Subject: Re: Avoiding a seq scan on a table.
Next
From: LWATCDR
Date:
Subject: Re: Avoiding a seq scan on a table.