Re: Dissapearing indexes, what's that all about? - Mailing list pgsql-general

From Tom Lane
Subject Re: Dissapearing indexes, what's that all about?
Date
Msg-id 484.986154465@sss.pgh.pa.us
Whole thread Raw
In response to Re: RE: RE: Re: Dissapearing indexes, what's that all about?  (Daniel ?erud <zilch@home.se>)
List pgsql-general
Daniel ?erud <zilch@home.se> writes:
> and filling it with 10000 rows made out of
> $pwgen 8 10000 > data [enter]
> and then running VACUUM and VACUUM ANALYZE
> still yields a sequential scan doing a
> select * from index_with where name > 'm';
> namely
> seq scan on index_with (cost=0.00..189 rows 5170 width=16)

So?  You're asking it to retrieve over half of the table (or at least
the planner estimates so, and I don't see any evidence here that its
estimate is wildly off).  An indexscan would still be a loser in this
scenario.

If you want to see an indexscan with an inequality query, try giving
it a reasonably tight range.  Probably

select * from index_with where name > 'm' and name < 'n';

would use the index in this example.

            regards, tom lane

pgsql-general by date:

Previous
From: Paul Tomblin
Date:
Subject: Ok, why isn't it using *this* index?
Next
From: Sean Harding
Date:
Subject: another index question