Re: Resume vacuum and autovacuum from interruption and cancellation
От | David Steele |
---|---|
Тема | Re: Resume vacuum and autovacuum from interruption and cancellation |
Дата | |
Msg-id | bb262d41-0f2c-87dd-5c26-39d188a35e50@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Resume vacuum and autovacuum from interruption and cancellation (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Список | pgsql-hackers |
On 2/28/20 8:56 AM, Masahiko Sawada wrote: > > According to those results, it's thought that the more we resume > vacuum from the tail of the table, the efficiency is good. Since the > table is being updated uniformly even during autovacuum it was more > efficient to restart autovacuum from last position rather than from > the beginning of the table. I think that results shows somewhat the > benefit of this patch but I'm concerned that it might be difficult for > users when to use this option. In practice the efficiency completely > depends on the dispersion of updated pages, and that test made pages > dirty uniformly, which is not a common situation. So probably if we > want this feature, I think we should automatically enable resuming > when we can basically be sure that resuming is better. For example, we > remember both the last vacuumed block and how many vacuum-able pages > seems to exist from there, and we decide to resume vacuum if we can > expect to process more many pages. I have to say I'm a bit confused by the point of this patch. I get that starting in progress is faster but that's only true because the entire table is not being vacuumed? If as you say: > If we start to vacuum from not first block, we can update neither > relfrozenxid nor relfrozenxmxid. And we might not be able to update > even relation statistics. Then we'll still need to vacuum the entire table before we can be sure the oldest xid has been removed/frozen. If we could do those updates on a resume then that would change my thoughts on the feature a lot. What am I missing? I'm marking this Returned with Feedback due concerns expressed up-thread (and mine) and because the patch has been Waiting on Author for nearly the entire CF. Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: