Skip site navigation (1) Skip section navigation (2)

Re: Experimental patch for inter-page delay in VACUUM

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Experimental patch for inter-page delay in VACUUM
Date: 2003-11-03 00:15:07
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Centuries ago, Nostradamus foresaw when "Stephen" <jleelim(at)xxxxxxx(dot)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

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, <> rate me
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.  <>

In response to


pgsql-hackers by date

Next:From: Gaetano MendolaDate: 2003-11-03 01:08:18
Subject: Re: Experimental patch for inter-page delay in VACUUM
Previous:From: Tom LaneDate: 2003-11-02 23:25:07
Subject: Re: PlayStation 2 problems

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group