From: | "Daniel T(dot) Staal" <DStaal(at)usa(dot)net> |
---|---|
To: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: Avoiding a seq scan on a table. |
Date: | 2008-01-14 17:22:57 |
Message-ID: | 52273.63.172.115.138.1200331377.squirrel@MageHandbook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On Mon, January 14, 2008 12:14 pm, 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))
Based on that cost, a sequence scan is probably the fastest yet: It's such
a small dataset that fetching the index and working with it before going
back and fetching the data is just overkill.
When you add a few dozen more rows or so, it'll switch to using the index.
Daniel T. Staal
---------------------------------------------------------------
This email copyright the author. Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes. This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | Sean Davis | 2008-01-14 17:25:43 | Re: Avoiding a seq scan on a table. |
Previous Message | LWATCDR | 2008-01-14 17:14:14 | Re: Avoiding a seq scan on a table. |