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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
