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

Re: Avoiding a seq scan on a table.

From: LWATCDR <lwatcdr(at)gmail(dot)com>
To: "Sean Davis" <sdavis2(at)mail(dot)nih(dot)gov>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: Avoiding a seq scan on a table.
Date: 2008-01-14 17:14:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-novice
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))

On Jan 14, 2008 11:54 AM, Sean Davis <sdavis2(at)mail(dot)nih(dot)gov> wrote:
> On Jan 14, 2008 11:45 AM, LWATCDR <lwatcdr(at)gmail(dot)com> wrote:
> > Thanks would you suggest a btree or a hash? My guess would a hash
> > since it uses an =.
> >
> You can pretty much ignore hash indexes in Postgres.  They are, in nearly
> every case (every case that I know of), slower than btree.  Just make the
> indexes using the default indexing scheme.  Again, do not forget to analyze
> the table after creating the indexes.
> Sean

In response to


pgsql-novice by date

Next:From: Daniel T. StaalDate: 2008-01-14 17:22:57
Subject: Re: Avoiding a seq scan on a table.
Previous:From: Brian HurtDate: 2008-01-14 17:03:58
Subject: Re: Avoiding a seq scan on a table.

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