Centuries ago, Nostradamus foresaw when "Stephen" <[EMAIL PROTECTED]> would write: > As it turns out. With vacuum_page_delay = 0, VACUUM took 1m20s (80s) > to complete, with vacuum_page_delay = 1 and vacuum_page_delay = 10, > both VACUUMs completed in 18m3s (1080 sec). A factor of 13 times! > This is for a single 350 MB table.
While it is unfortunate that the minimum quanta seems to commonly be 10ms, it doesn't strike me as an enormous difficulty from a practical perspective. Well, actually, the case where it _would_ be troublesome would be where there was a combination of huge tables needing vacuuming and smaller ones that are _heavily_ updated (e.g. - account balances), where pg_autovacuum might take so long on some big tables that it wouldn't get to the smaller ones often enough. But even in that case, I'm not sure the loss of control is necessarily a vital problem. It certainly means that the cost of vacuuming has a strictly limited "degrading" effect on performance. It might be mitigated by the VACUUM CACHE notion I have suggested, where a Real Quick Vacuum would go through just the pages that are cached in memory, which would likely be quite effective at dealing with heavily-updated balance tables... -- If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me http://www3.sympatico.ca/cbbrowne/sap.html Rules of the Evil Overlord #212. "I will not send out battalions composed wholly of robots or skeletons against heroes who have qualms about killing living beings. <http://www.eviloverlord.com/> ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
