Skip site navigation (1) Skip section navigation (2)

Re: Avoiding a seq scan on a table.

From: Brian Hurt <bhurt(at)janestcapital(dot)com>
To: LWATCDR <lwatcdr(at)gmail(dot)com>
Cc: Sean Davis <sdavis2(at)mail(dot)nih(dot)gov>, pgsql-novice(at)postgresql(dot)org
Subject: Re: Avoiding a seq scan on a table.
Date: 2008-01-14 17:28:09
Message-ID: 478B9BA9.3060504@janestcapital.com (view raw or flat)
Thread:
Lists: 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


In response to

pgsql-novice by date

Next:From: Alan HodgsonDate: 2008-01-14 17:30:30
Subject: Re: Avoiding a seq scan on a table.
Previous:From: Sean DavisDate: 2008-01-14 17:25:43
Subject: Re: Avoiding a seq scan on a table.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group