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: | 8c38cea40801140914m41328019i33b37d652478b8b0@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel T. Staal | 2008-01-14 17:22:57 | Re: Avoiding a seq scan on a table. |
Previous Message | Brian Hurt | 2008-01-14 17:03:58 | Re: Avoiding a seq scan on a table. |