Re: Seqscan/Indexscan still a known issue?

Carlos Moreno <moreno_pg(at)mochima(dot)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