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

Re: Resumable vacuum proposal and design overview

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Galy Lee" <lee(dot)galy(at)oss(dot)ntt(dot)co(dot)jp>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"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 10:19:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> > The things I wanted to say is that:
> > If we can stop at any point, we can make maintenance memory large 
> > sufficient to contain all of the dead tuples, then we only need to 
> > clean index for once. No matter how many times vacuum 
> stops, indexes 
> > are cleaned for once.
> I agree that the cycle-at-a-time approach could perform more 
> poorly with repeated stop-start. The reason for the 
> suggestion was robustness, not performance. If you provide 

It performs more poorly, but it also gives immediate gain, since part of
the table is readily vacuumed. If you do it all in one pass with stop
resume, the first visible effect may be several days after you start
vacuuming. And, basically you need to pretend the vacuum transaction is
still running after the first stop. Else dead tuple reuse ala HOT is not
possible (or the ctid list needs to be reevaluated during resume, which
per se is not efficient). 

> the wrong dead-tuple-list to VACUUM, you will destroy the 
> integrity of a table, which can result in silent data loss. 
> You haven't explained how saving the dead-tuple-list could be 
> done in a safe mannner and it seems risky to me.

Agreed. It seems not efficiently possible.


In response to


pgsql-hackers by date

Next:From: Zeugswetter Andreas ADI SDDate: 2007-02-28 10:34:14
Subject: Re: Resumable vacuum proposal and design overview
Previous:From: Galy LeeDate: 2007-02-28 10:02:45
Subject: Re: Resumable vacuum proposal and design overview

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