Centuries ago, Nostradamus foresaw when "Stephen" <jleelim@xxxxxxx.com> 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/>
