From: | "Sean Davis" <sdavis2(at)mail(dot)nih(dot)gov> |
---|---|
To: | LWATCDR <lwatcdr(at)gmail(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Avoiding a seq scan on a table. |
Date: | 2008-01-14 17:25:43 |
Message-ID: | 264855a00801140925x3208fa30x98ad59547a8679cc@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On Jan 14, 2008 12:14 PM, LWATCDR <lwatcdr(at)gmail(dot)com> 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))
The Postgres planner will choose what it thinks is the fastest plan. In
this case, your table has only 1 row (?), so sequential scan will be
fastest. You will want to load data into your table before doing
benchmarking.
Sean
From | Date | Subject | |
---|---|---|---|
Next Message | Brian Hurt | 2008-01-14 17:28:09 | Re: Avoiding a seq scan on a table. |
Previous Message | Daniel T. Staal | 2008-01-14 17:22:57 | Re: Avoiding a seq scan on a table. |