Re: Does cancelling autovacuum make you lose all the work it did?
От | Tom Lane |
---|---|
Тема | Re: Does cancelling autovacuum make you lose all the work it did? |
Дата | |
Msg-id | 781873.1591994026@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Does cancelling autovacuum make you lose all the work it did? ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: [EXT] Re: Does cancelling autovacuum make you lose all the workit did?
|
Список | pgsql-novice |
"David G. Johnston" <david.g.johnston@gmail.com> writes: > To answer the original question: vacuum's effects are basically immediate > so work is not lost if it gets cancelled. Mmm ... not entirely true. vacuum does a cycle like this: 1. scan table looking for removable rows; remember their TIDs 2. when memory for said TIDs is full, make a pass over the table's indexes to find and delete index entries pointing at those TIDs 3. then, go back to the heap pages and actually remove the rows 4. if we didn't reach the end of the table yet, return to step 1. If we get cancelled at any point, the data structure is still consistent; there may be heap rows that don't have a full set of index entries, but that doesn't matter because nobody cares about finding those entries from the indexes. However, when you redo the vacuum, it'll have to redo some of the work from the current cycle, depending on exactly how far along it was when you cancelled it. At the very least it's going to be repeating some heap-scanning work, though that's the cheapest part of this because it's basically read-only. The most expensive parts are the actual index and heap tuple removals, and any one of those won't need to be done over. The size of the cycles depends on maintenance_work_mem; so if you have that set really large, you can lose more time than if it's not so large. TBH, though, are you sure the vacuum is doing work and not just blocked waiting for somebody else? An autovac can be blocked indefinitely by some other query holding a table-level or page-level lock. Check its state in pg_stat_activity. regards, tom lane
В списке pgsql-novice по дате отправления: