Hi Alvaro and All,
On 2019/08/13 14:40, Tatsuro Yamada wrote:
> Hi Alvaro!
>
> On 2019/08/02 3:43, Alvaro Herrera wrote:
>> Hmm, I'm trying this out now and I don't see the index_rebuild_count
>> ever go up. I think it's because the indexes are built using parallel
>> index build ... or maybe it was the table AM changes that moved things
>> around, not sure. There's a period at the end when the CLUSTER command
>> keeps working, but it's gone from pg_stat_progress_cluster.
>
>
> Thanks for your report.
> I'll investigate it. :)
I did "git bisect" and found the commit:
03f9e5cba0ee1633af4abe734504df50af46fbd8
Report progress of REINDEX operations
In src/backend/catalog/index.c,
CLUSTER progress reporting increases index_rebuild_count in reindex_relation()
by pgstat_progress_update_param().
However, reindex_relation() calls reindex_index(), and REINDEX progress reporting is existing on the latter function,
andit starts pgstat_progress_start_command() pgstat_progress_end_command() for REINDEX progress reporting.
Therefore, CLUSTER progress reporting failed to update index_rebuild_count because
it made a mistake to update the REINDEX's view, I think.
My Idea to fix that is following:
- Add a target view name parameter to Progress monitor's API
For example:
<Before>
pgstat_progress_update_param(PROGRESS_CLUSTER_INDEX_REBUILD_COUNT, i).
<After>
pgstat_progress_update_param(*PROGRESS_CLUSTER_VIEW*, PROGRESS_CLUSTER_INDEX_REBUILD_COUNT, i).
However, I'm not sure whether it is able or not because I haven't read
the code of the API yet.
What do you think about that? :)
Thanks,
Tatsuro Yamada