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

Re: Resumable vacuum proposal and design overview

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Resumable vacuum proposal and design overview
Date: 2007-02-28 03:48:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Galy Lee <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Tom Lane wrote:
>> ... or set a flag to stop at the next cycle-completion point.

> The extra cost to clean indexes may prevent this approach to work in
> practices.

Huh?  There is no extra cost in what I suggested; it'll perform
exactly the same number of index scans that it would do anyway.

>> Perhaps a more useful answer to the problem of using a
>> defined maintenance window is to allow VACUUM to respond to changes in
>> the vacuum cost delay settings on-the-fly.

> This is a good idea! Itagaki also have talked about exactly the same
> idea to me yesterday.

> But if we change the parameters on-fly to make vacuum less aggressive,
> my concern is that: is there any potential problems to run vacuum in
>  several days?

If the table is sufficiently large, that could happen anyway.  The
issues here, I think, are to not eat resources that foreground processes
need (which vacuum-cost-delay addresses) and to not block vacuuming of
hot-update tables (which can be addressed by allowing multiple autovac
workers).  So I'm not really convinced that being able to stop a table
vacuum halfway is critical.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: John BartlettDate: 2007-02-28 04:14:54
Subject: Re: - WIP Patch Updatable Cursor
Previous:From: Jonah H. HarrisDate: 2007-02-28 03:43:53
Subject: Re: COMMIT NOWAIT Performance Option

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