Re: Re: Dissapearing indexes, what's that all about?

Wohooo,
deluxe :-)

THANKS EVERYBODY!!

Can't see the logic behind that though
The jump in the b-tree must save about 5000 checks... half
the table??

Thanks!

Daniel Åkerud

> Daniel ?erud <zilch(at)home(dot)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
>