Re: Seqscan/Indexscan still a known issue?

From: Carlos Moreno <moreno_pg(at)mochima(dot)com>
To:
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Seqscan/Indexscan still a known issue?
Date: 2007-01-27 21:14:44
Message-ID: 45BBC0C4.9020204@mochima.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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
--

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Ryan Holmes 2007-01-27 23:34:56 IN operator causes sequential scan (vs. multiple OR expressions)
Previous Message Tom Lane 2007-01-27 17:28:11 Re: Seqscan/Indexscan still a known issue?