Re: Seqscan/Indexscan still a known issue?
| От | Tom Lane |
|---|---|
| Тема | Re: Seqscan/Indexscan still a known issue? |
| Дата | |
| Msg-id | 6888.1169918891@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Seqscan/Indexscan still a known issue? (Carlos Moreno <moreno_pg@mochima.com>) |
| Ответы |
Re: Seqscan/Indexscan still a known issue?
|
| Список | 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 по дате отправления: