Re: Resumable vacuum proposal and design overview
| От | Tom Lane |
|---|---|
| Тема | Re: Resumable vacuum proposal and design overview |
| Дата | |
| Msg-id | 4403.1172515180@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Resumable vacuum proposal and design overview (tomas@tuxteam.de) |
| Ответы |
Re: Resumable vacuum proposal and design overview
|
| Список | 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 по дате отправления: