Re: [PROPOSAL] VACUUM Progress Checker.
От | Jim Nasby |
---|---|
Тема | Re: [PROPOSAL] VACUUM Progress Checker. |
Дата | |
Msg-id | 565501A3.30605@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [PROPOSAL] VACUUM Progress Checker. (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: [PROPOSAL] VACUUM Progress Checker.
|
Список | pgsql-hackers |
On 11/24/15 2:02 AM, Amit Langote wrote: >> It just occurred to me that we could do the instrumentation in >> >lazy_tid_reaped(). It might seem bad to do in increment for every tuple in >> >an index, but we're already doing a bsearch over the dead tuple list. >> >Presumably that's going to be a lot more expensive than an increment >> >operation. > Just to clarify, does this mean we report index vacuum progress in terms > of index items processed (not pages)? If so, how do we get total number of > index items to process (presumably across all indexes) for a given phase 2 > round? As a context, we'd report phase 1 progress in terms of heap pages > processed of total heap pages. You'd get it from pg_class.reltuples for each index. Since all index vacuuming is done strictly on a per-index-tuple basis, that's probably the most accurate way to do it anyway. Also, while it might be interesting to look at the total number of index tuples, I think it's probably best to always report on a per-index basis, as well as which index is being processed. I suspect there could be a very large variance of tuple processing speed for different index types. Eventually it might be worth it to allow index AMs to provide their own vacuuming feedback, but I think that's way out of scope for this patch. :) -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: