Skip site navigation (1) Skip section navigation (2)

Re: Seqscan/Indexscan still a known issue?

From: Carlos Moreno <moreno_pg(at)mochima(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Seqscan/Indexscan still a known issue?
Date: 2007-01-27 21:14:44
Message-ID: (view raw, whole thread or download thread mbox)
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

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!



In response to

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group