Re: Index not being used

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Ralph Smith" <smithrn(at)u(dot)washington(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Index not being used
Date: 2007-08-13 23:39:46
Message-ID: dcc563d10708131639w66424aeg9b2fdb632012f903@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 8/13/07, Ralph Smith <smithrn(at)u(dot)washington(dot)edu> wrote:
> I'm confused. Shouldn't this index be used?
> (It's running on v7.4.7)
>
> airburst=> \d stats2
> Table "public.stats2"
> Column | Type | Modifiers
> -----------+-----------------------+-----------
> lab | character varying(30) |
> name | character varying(50) |
> status | character varying(40) |
> eventtime | integer |
> username | character varying(30) |
> pkey | character varying(60) |
> Indexes:
> "stats2_etime_index" btree (eventtime)
>
> airburst=> \d stats2_etime_index
> Index "public.stats2_etime_index"
> Column | Type
> -----------+---------
> eventtime | integer
> btree, for table "public.stats2"
>
> airburst=> explain select count(*) from stats2 where eventtime > 1167638400
> ;
> QUERY PLAN
> -----------------------------------------------------------------------
> Aggregate (cost=185247.97..185247.97 rows=1 width=0)
> -> Seq Scan on stats2 (cost=0.00..179622.45 rows=2250205 width=0)
> Filter: (eventtime > 1167638400)
> (3 rows)

That really depends. how many rows are actually returned? If it's
2250205 like the query planner thinks, and that's a fair chunk of the
table, then no, it shouldn't use an index, a seq scan will be faster.
What does explain analyze select ... say?

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ralph Smith 2007-08-14 00:24:30 Re: Index not being used
Previous Message Ralph Smith 2007-08-13 23:25:19 Index not being used