From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, <pokurev(at)pm(dot)nttdata(dot)co(dot)jp>, "Robert Haas (robertmhaas(at)gmail(dot)com)" <robertmhaas(at)gmail(dot)com> |
Subject: | Re: [PROPOSAL] VACUUM Progress Checker. |
Date: | 2015-11-25 00:32:35 |
Message-ID: | 565501A3.30605@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-11-25 00:33:19 | Re: Using quicksort for every external sort run |
Previous Message | Michael Paquier | 2015-11-25 00:08:33 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |