Re: Resumable vacuum proposal and design overview - Mailing list pgsql-hackers

From Zeugswetter Andreas ADI SD
Subject Re: Resumable vacuum proposal and design overview
Date
Msg-id E1539E0ED7043848906A8FF995BDA57901CAFD2D@m0143.s-mxs.net
Whole thread Raw
In response to Re: Resumable vacuum proposal and design overview  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: Resumable vacuum proposal and design overview  ("Simon Riggs" <simon@2ndquadrant.com>)
List 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.

Andreas



pgsql-hackers by date:

Previous
From: Galy Lee
Date:
Subject: Re: Resumable vacuum proposal and design overview
Next
From: "Zeugswetter Andreas ADI SD"
Date:
Subject: Re: Resumable vacuum proposal and design overview