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 по дате отправления: