Hi there,
> show us explain analyze output.
Here we go:
---this one is using the index on "ranking"
SELECT *
FROM ttm_slots s
WHERE s.peering = 72
AND s.ranking = 1050
explain:
Index Scan using ranking_ttm_slots_key on ttm_slots s (cost=0.00..191.06
rows=8 width=62)
---but this one does not?
SELECT *
FROM ttm_slots s
WHERE s.peering = 72
AND s.ranking < 1050
AND s.ranking > 950
explain:
Seq Scan on ttm_slots s (cost=0.00..1823.64 rows=7949 width=62)
The index ist "btree", so it should be able to use the index with a < >
comparison?
\d ranking_ttm_slots_key
Index "ranking_ttm_slots_key"
Column | Type
---------+---------
ranking | integer
btree
regards,
// Jan-Philipp 'Thefly' Reining
----- Original Message -----
From: "Hubert depesz Lubaczewski" <depesz@depesz.pl>
To: "Jan-Philipp 'Thefly' Reining" <jpr@turtle-entertainment.de>;
<pgsql-general@postgresql.org>
Sent: Saturday, November 30, 2002 1:20 AM
Subject: Re: [GENERAL] The old "not using index" question
> On Fri, Nov 29, 2002 at 05:37:04PM +0100, Jan-Philipp 'Thefly' Reining
wrote:
> > ---but this one does not?
> > SELECT *
> > FROM ttm_slots s
> > WHERE s.peering = 72
> > AND s.ranking < 1050
> > AND s.ranking > 950
> >
> > The index ist "btree", so it should be able to use the index with a < >
> > comparison?
>
> show us explain analyze output.
> probably planner thinks there are too many rows matching this criteria
> to use index.
>
> depesz
>
> --
> hubert depesz lubaczewski http://www.depesz.pl/
> ------------------------------------------------------------------------
> Mój Boże, spraw abym milczał, dopóki się nie upewnię, że naprawdę mam
> coś do powiedzenia. (c) 1998 depesz
>
>