Re: Seqscan/Indexscan still a known issue?

Поиск
Список
Период
Сортировка
От Carlos Moreno
Тема Re: Seqscan/Indexscan still a known issue?
Дата
Msg-id 45BBC0C4.9020204@mochima.com
обсуждение исходный текст
Ответ на Re: Seqscan/Indexscan still a known issue?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Tom Lane wrote:

> One reason you might consider updating is that newer versions check the
>
>physical table size instead of unconditionally believing
>pg_class.relpages/reltuples.  Thus, they're much less likely to get
>fooled when a table has grown substantially since it was last vacuumed
>or analyzed.
>
>

Sounds good.  Obviously, there seem to be plenty of reasons to
upgrade, as pointed out in several of the previous replies;  I
would not rank this one as one of the top reasons to upgrade,
since every time I've encountered this issue (planner selecting
seq. scan when I'm convinced it should choose an index scan), I
can always get away with forcing it to use an index scan, even
if it feels like the wrong solution.

But still, I guess what you point out comes as part of an array
of improvements that will contribute to much better performance
anyway!

I'm sure I've said it countless times, but it feels again like
the right time to say it:  thank you so much for all the help
and all the effort the PG team has put in making this such a
great product --- improvement after improvement!

Thanks,

Carlos
--


В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Seqscan/Indexscan still a known issue?
Следующее
От: Ryan Holmes
Дата:
Сообщение: IN operator causes sequential scan (vs. multiple OR expressions)