Re: Really really slow select count(*)

On 02/04/2011 11:38 AM, felix wrote:

> CPU 0.00s/0.00u sec elapsed 0.00 sec.
> INFO: analyzing "public.fastadder_fastadderstatus"
> INFO: "fastadder_fastadderstatus": scanned 2492 of 2492 pages,
> containing 154378 live rows and 0 dead rows; 30000 rows in sample,
> 154378 estimated total rows
>
> and there's nothing at the end of the whole vacuum output about pages

I'm not sure if it gives it to you if you pick a single DB, but if you
use -a for all, you should get something at the very end like this:

INFO: free space map contains 1365918 pages in 1507 relations
DETAIL: A total of 1326656 page slots are in use (including overhead).
1326656 page slots are required to track all free space.
Current limits are: 3000000 page slots, 3500 relations, using 38784 kB.
VACUUM

That's on our dev system. Your dev table seems properly sized, but prod
probably isn't. If you run an all-database vacuum after-hours, you'll
see the stuff at the end. And if your 'page slots are required' is
greater than your 'page slots are in use,' you've got a problem.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas(at)peak6(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email