Re: Add index scan progress to pg_stat_progress_vacuum - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Add index scan progress to pg_stat_progress_vacuum
Date
Msg-id CAD21AoD-HQHRVUtmykgdOigN1bxjcuXecmN76WYrQTLH2fuyyQ@mail.gmail.com
Whole thread Raw
In response to Re: Add index scan progress to pg_stat_progress_vacuum  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Responses Re: Add index scan progress to pg_stat_progress_vacuum  ("Imseih (AWS), Sami" <simseih@amazon.com>)
List pgsql-hackers
On Sat, Feb 18, 2023 at 11:46 AM Imseih (AWS), Sami <simseih@amazon.com> wrote:
>
> Thanks for the review!
>
> >    +     <row>
> >    +      <entry><literal>ParallelVacuumFinish</literal></entry>
> >    +      <entry>Waiting for parallel vacuum workers to finish index
> >    vacuum.</entry>
> >    +     </row>
>
> >    This change is out-of-date.
>
> That was an oversight. Thanks for catching.
>
> >    Total number of indexes that will be vacuumed or cleaned up. This
> >    number is reported as of the beginning of the vacuuming indexes phase
> >    or the cleaning up indexes phase.
>
> This is cleaner. I was being unnecessarily verbose in the original description.
>
> >    Number of indexes processed. This counter only advances when the phase
> >    is vacuuming indexes or cleaning up indexes.
>
> I agree.
>
> >    Also, index_processed sounds accurate to me. What do you think?
>
> At one point, II used index_processed, but decided to change it.
> "processed" makes sense also. I will use this.
>
> >    I think these settings are not necessary since the pcxt is palloc0'ed.
>
> Good point.
>
> >    Assert(pvs->pcxt->parallel_progress_callback_arg) looks wrong to me.
> >    If 'arg' is NULL, a SEGV happens.
>
> Correct, Assert(pvs) is all that is needed.
>
> >    I think it's better to update pvs->shared->nindexes_completed by both
> >    leader and worker processes who processed the index.
>
> No reason for that, since only the leader process can report process to
> backend_progress.
>
>
> >    I think it's better to make the function type consistent with the
> >    existing parallel_worker_main_type. How about
> >    parallel_progress_callback_type?
>
> Yes, that makes sense.
>
> > I've attached a patch that incorporates the above comments and has
> >    some suggestions of updating comments etc.
>
> I reviewed and incorporated these changes, with a slight change. See v24.
>
> -        * Increase and report the number of index. Also, we reset the progress
> -        * counters.
>
>
> +        * Increase and report the number of index scans. Also, we reset the progress
> +        * counters.
>
>
> Thanks

Thanks for updating the patch!

 #define PROGRESS_VACUUM_NUM_INDEX_VACUUMS              4
 #define PROGRESS_VACUUM_MAX_DEAD_TUPLES                        5
 #define PROGRESS_VACUUM_NUM_DEAD_TUPLES                        6
+#define PROGRESS_VACUUM_INDEX_TOTAL             7
+#define PROGRESS_VACUUM_INDEX_PROCESSED         8

-    s.param7 AS num_dead_tuples
+    s.param7 AS num_dead_tuples,
+    s.param8 AS indexes_total,
+    s.param9 AS indexes_processed

I think PROGRESS_VACUUM_INDEXES_TOTAL and
PROGRESS_VACUUM_INDEXES_PROCESSED are better for consistency. The rest
looks good to me.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Allow logical replication to copy tables in binary format
Next
From: Amit Langote
Date:
Subject: Re: SQL/JSON revisited