From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | 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 17:28:11 |
Message-ID: | 6888.1169918891@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Carlos Moreno | 2007-01-27 21:14:44 | Re: Seqscan/Indexscan still a known issue? |
Previous Message | Carlos Moreno | 2007-01-27 17:09:16 | Re: Seqscan/Indexscan still a known issue? |