>> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
