From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: progress reporting for partitioned REINDEX |
Date: | 2021-02-20 02:40:11 |
Message-ID: | 20210220024011.GL14772@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Feb 20, 2021 at 10:37:08AM +0900, Michael Paquier wrote:
> > Also, I noticed that vacuum recurses into partition heirarchies since v10, but
> > pg_stat_progress_vacuum also doesn't show anything about the parent table or
> > the progress of recursing through the hierarchy.
>
> Yeah, that's an area where it would be possible to improve the
> monitoring, for both autovacuums and manual VACUUMs.
I was thinking that instead of reporting partitions_done/partitions_total in
the individual progress views, maybe the progress across partitions should be
reported in a separate pg_stat_progress_partitioned. This would apply to my
CLUSTER patch as well as VACUUM. I haven't though about the implementation,
though.
If the partitions_done/total were *removed* from the create_index view, that
would resolve the odd behavior that a single row simultanously shows 1) the
overall progress of the operation across partitions; and, 2) the detailed
information about the status of the operation on the current leaf partition.
However I guess it's not general enough to support progress reports of
execution of planned (not utility) statements.
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2021-02-20 03:38:03 | Re: repeated decoding of prepared transactions |
Previous Message | Andy Fan | 2021-02-20 02:25:59 | UniqueKey on Partitioned table. |