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

From Daniel ?erud
Subject Re: Re: Dissapearing indexes, what's that all about?
Date
Msg-id 986155592.177zilch@home.se
Whole thread Raw
In response to Dissapearing indexes, what's that all about?  (Daniel ?erud <zilch@home.se>)
Responses Re: Dissapearing indexes, what's that all about?
List pgsql-general
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@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: Mike Mascari
Date:
Subject: RE: Ok, why isn't it using *this* index?
Next
From: Tom Lane
Date:
Subject: Re: Ok, why isn't it using *this* index?