On Sat, Mar 26, 2011 at 8:05 PM, Jan Wieck <janwi...@yahoo.com> wrote: > On 3/26/2011 12:12 PM, Simon Riggs wrote: >> >> On Sat, Mar 26, 2011 at 2:30 PM, Jan Wieck<janwi...@yahoo.com> wrote: >> >>> My current idea for a fix is to modify lazy_truncate_heap(). It does >>> acquire >>> and release the exclusive lock, so it should be possible to do this in >>> smaller chunks, releasing and reacquiring the lock so that client >>> transactions can get their work done as well. >> >> Agreed, presumably with vacuum delay in there as well? > > Not sure about that. My theory is that unless somebody needs access to that > table, just have at it like it is now. > > The current implementation seems to assume that the blocks, checked for > being empty, are still found in memory (vacuum just scanned them). And that > seems to be correct most of the time, in which case adding vacuum delay only > gives more time that the blocks get evicted and have to be read back in.
I think someone fairly clever already thought of that. vacuum_cost_page_hit = 1 by default, so the cost of accessing pages still in memory is 1/10th the cost of disk access. So we will only perform the delay for each chunk if we had to read it from disk. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
