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

Re: autovacuum next steps, take 2

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Hackers <pgsql-hackers(at)postgresql(dot)org>, Gregory Stark <stark(at)enterprisedb(dot)com>
Subject: Re: autovacuum next steps, take 2
Date: 2007-02-27 05:57:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> "Jim C. Nasby" <jim(at)nasby(dot)net> writes:
>> The proposal to save enough state to be able to resume a vacuum at
>> pretty much any point in it's cycle might work; we'd have to benchmark
>> it.  With the default maintenance_work_mem of 128M it would mean writing
>> out 64M of state every minute on average, which is likely to take
>> several seconds to fsync (though, maybe we wouldn't need to fsync it...)
> Which is exactly why we needn't bother benchmarking it.  Even if it
> weren't complex and unsafe, it will be a net loss when you consider the
> fact that it adds I/O instead of removing it.

I'm not sure what you are saying here, are you now saying that partial 
vacuum won't work for autovac?  Or are you saying that saving state as 
Jim is describing above won't work?

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2007-02-27 06:20:30
Subject: Re: autovacuum next steps, take 2
Previous:From: Tom LaneDate: 2007-02-27 05:55:21
Subject: Re: Dead Space Map version 2

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