From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(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:43:22 |
Message-ID: | 20070227054322.GP29041@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 27, 2007 at 12:37:42AM -0500, 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.
Well, it depends on how often you're doing that. Adding extra IO at the
end of 4 hours of vacuuming isn't going to make any real difference, but
once a minute...
Looks like partial vacuum won't help this problem. :(
--
Jim Nasby jim(at)nasby(dot)net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2007-02-27 05:45:19 | Re: COMMIT NOWAIT Performance Option |
Previous Message | Jim C. Nasby | 2007-02-27 05:41:18 | Re: autovacuum next steps, take 2 |