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

From Tom Lane
Subject Re: Resumable vacuum proposal and design overview
Date
Msg-id 4403.1172515180@sss.pgh.pa.us
Whole thread Raw
In response to Re: Resumable vacuum proposal and design overview  (tomas@tuxteam.de)
Responses Re: Resumable vacuum proposal and design overview  (tomas@tuxteam.de)
List pgsql-hackers
tomas@tuxteam.de writes:
> WARNING: I don't really know what I'm talking about -- but considering
> that vaccuming a large table across several "maintainance windows" is
> one of the envisioned scenarios, it might make sense to try to update
> the statistics (i.e. to do partially step 7) on each partial run.
> Otherwise the table's stats might wander off for quite long times?

You can handle that by issuing ANALYZE as a separate operation; I see no
need to complicate this proposal even further by having it make magic
changes to the behavior of VACUUM ANALYZE.

Or were you speaking of the pg_class.reltuples count?  Keeping that
from diverging indefinitely far from reality will indeed be a problem
with this sort of thing.  We've already seen some issues related to the
stats collector's similar count.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: conversion efforts (Re: SCMS question)
Next
From: Warren Turkal
Date:
Subject: Re: conversion efforts (Re: SCMS question)