Re: seq-scan or index-scan

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Andreas Kretschmer <akretschmer(at)spamfence(dot)net> writes:
> > production=*# explain analyse select * from boxes;
> > QUERY PLAN
> > ---------------------------------------------------------------------------------------------------------------
> > Seq Scan on boxes (cost=0.00..990783.99 rows=6499 width=581) (actual time=6.514..4588.136 rows=3060 loops=1)
> > Total runtime: 4588.729 ms
> > (2 rows)
>
> That cost estimate seems pretty dang large for a table with only 6500
> rows. I suspect this table is horribly bloated, and the indexscan
> manages to win because it's not visiting pages that contain only dead

You're right as always ;-)

A LOT of updates and dead rows and the table is bloated.
(some rows contains more than 1MByte of TEXT and some rows updated once
per second or so)

> rows. Try VACUUM FULL, and if that makes things saner, re-examine
> your autovacuum settings.

I can't run a VACUUM FULL because of the workload, but i have decrease
the fillfactor.

Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
unintentional side effect. (Linus Torvalds)
"If I was god, I would recompile penguin with --enable-fly." (unknown)
Kaufbach, Saxony, Germany, Europe. N 51.05082°, E 13.56889°