Re: RFC: changing autovacuum_naptime semantics

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: changing autovacuum_naptime semantics
Date: 2007-03-09 05:42:41
Message-ID: 21674.1173418961@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Now regarding your restartable vacuum work. I think that stopping a
> vacuum at some point and being able to restart it later is very cool and
> may get you some hot chicks, but I'm not sure it's really useful.

Too true :-(

> I think it makes more sense to do something like throttling an ongoing
> vacuum to a reduced IO rate, if the maintenance window closes. So if
> you're in the middle of a heap scan and the maintenance window closes,
> you immediately stop the scan and go the the index cleanup phase, *at a
> reduced IO rate*.

Er, why not just finish out the scan at the reduced I/O rate? Any sort
of "abort" behavior is going to create net inefficiency, eg doing an
index scan to remove only a few tuples. ISTM that the vacuum ought to
just continue along its existing path at a slower I/O rate.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2007-03-09 05:51:11 Re: Log levels for checkpoint/bgwriter monitoring
Previous Message ITAGAKI Takahiro 2007-03-09 02:04:58 Re: Log levels for checkpoint/bgwriter monitoring