Re: Add index scan progress to pg_stat_progress_vacuum

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "Imseih (AWS), Sami" <simseih(at)amazon(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add index scan progress to pg_stat_progress_vacuum
Date: 2023-02-20 07:14:20
Message-ID: CAD21AoD-HQHRVUtmykgdOigN1bxjcuXecmN76WYrQTLH2fuyyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 18, 2023 at 11:46 AM Imseih (AWS), Sami <simseih(at)amazon(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2023-02-20 07:35:52 Re: SQL/JSON revisited
Previous Message Hayato Kuroda (Fujitsu) 2023-02-20 07:12:03 RE: Allow logical replication to copy tables in binary format