From: | "Greg Sikorski" <gte(at)atomicrevs(dot)demon(dot)co(dot)uk> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: <= Index. |
Date: | 2002-03-31 14:48:47 |
Message-ID: | OF12E0FEFE.59B34BA8-ON80256B8D.0050F0AD-80256B8D.00515EF1@atomicrevs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
pgsql-admin-owner(at)postgresql(dot)org wrote on 31/03/2002 08:06:52:
> Greg Sikorski writes:
>
> > How come this Index isn't being used in the situation below?
>
> There's no point in using an index if you're retrieving nearly the
entire
> table.
>
> --
> Peter Eisentraut peter_e(at)gmx(dot)net
>
>
Well, that was probably a poor example to include, but it was nearly 4am
;)
Typically <20 results are returned, although it still says "Seq Scan", but
on a smaller subset.
--
cmaster=# SELECT user_id,channel_id FROM levels WHERE suspend_expires <=
1017589362 AND suspend_expires <> 0;
user_id | channel_id
---------+------------
...
(17 rows)
cmaster=# explain analyze SELECT user_id,channel_id FROM levels WHERE
suspend_expires <= 1017589362 AND suspend_expires <> 0;
NOTICE: QUERY PLAN:
Seq Scan on levels (cost=0.00..13709.09 rows=2609 width=8) (actual
time=208.98..1521.08 rows=17 loops=1)
Total runtime: 1521.29 msec
Cheers, Greg.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-03-31 15:28:09 | Re: <= Index. |
Previous Message | Peter Eisentraut | 2002-03-31 07:06:52 | Re: <= Index. |