>> INFO: "cpe": found 95498 removable, 18757 nonremovable row versions
>> in 11117 pages
>> DETAIL: 0 dead row versions cannot be removed yet.
>> There were 280173 unused item pointers.
>> 0 pages are entirely empty.
>> CPU 5.35s/0.99u sec elapsed 724.38 sec.
>>
>> Then, running vacuum again immediately afterword, on a system that was
>> basically idle, would result in nearly the same amount of time to
>> vacuum the table.
>
> You do realize that except for the end of a table, vacuum recovers no
> actual space, just makes it available for new tuples to move in there.
> So it makes sense that the second vacuum would take just as long, or
> nearly so.
>
Yep. The real issue is that it took 724 seconds, instead of say, a
half second - like it does on my system. I wasn't sure if I should
expect vacuum to take longer to run when it finds a large number of
tuples that it needs to make available, so I just have them run it
twice so I can easily compare the time that it takes with essentially
no work to do.
>
> Hard to say. Have them run
>
> vmstat 1
>
> while vacuuming and see what bi/bo look like.
>
Haven't looked at that yet on this particular system. Last time, on
different hardware when this occurred the vmstat 'wa' column showed
very large values while vacuum was running. I don't recall what the
bi/bo columns indicated.
top also showed very high load averages while vacuum was running - but
basically no cpu use.
Are there any common tools that could do a better disk benchmark than
hdparm -Tt?
Thanks,
Dan