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

Поиск
Список
Период
Сортировка
От Daniel ?erud
Тема Re: Re: Dissapearing indexes, what's that all about?
Дата
Msg-id 986155592.177zilch@home.se
обсуждение исходный текст
Ответ на Dissapearing indexes, what's that all about?  (Daniel ?erud <zilch@home.se>)
Ответы Re: Dissapearing indexes, what's that all about?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Mike Mascari
Дата:
Сообщение: RE: Ok, why isn't it using *this* index?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Ok, why isn't it using *this* index?