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
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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to