Re: Seqscan/Indexscan still a known issue? - Mailing list pgsql-performance

From Tom Lane
Subject Re: Seqscan/Indexscan still a known issue?
Date
Msg-id 6888.1169918891@sss.pgh.pa.us
Whole thread Raw
In response to Re: Seqscan/Indexscan still a known issue?  (Carlos Moreno <moreno_pg@mochima.com>)
Responses Re: Seqscan/Indexscan still a known issue?
List pgsql-performance
Carlos Moreno <moreno_pg@mochima.com> writes:
> But I think the problem is that this particular table had not been
> vacuum analyzed after having inserted the 20000 records  (the
> query planner was giving me seq. scan when the table had about
> a dozen records --- and seq. scan was, indeed, 10 times faster;
> as a test, to make sure that the query planner would do the right
> thing when the amount of records was high, I inserted 20000
> records, and tried again --- now the seq. scan was 100 times
> slower, but it was still chosen  (at that point was that I did a
> search through the archives and then posted the question).

> But now, after reading the replies, I did a vacuum analyze for
> this table, and now the query planner is choosing the Index
> scan.

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.

            regards, tom lane

pgsql-performance by date:

Previous
From: Carlos Moreno
Date:
Subject: Re: Seqscan/Indexscan still a known issue?
Next
From: Carlos Moreno
Date:
Subject: Re: Seqscan/Indexscan still a known issue?