Re: Seqscan/Indexscan still a known issue?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--



[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux