From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andreas Kretschmer <akretschmer(at)spamfence(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: seq-scan or index-scan |
Date: | 2012-07-03 16:13:55 |
Message-ID: | 8958.1341332035@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
rows. Try VACUUM FULL, and if that makes things saner, re-examine
your autovacuum settings.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Benedict Holland | 2012-07-03 18:07:54 | function ave(integer) does not exist |
Previous Message | Tomas Vondra | 2012-07-03 16:07:52 | Re: seq-scan or index-scan |