Hi,
> The simpler approach is to have workers report the index they're
> currently on into their own st_progress_param[] slots, which already
> exist per backend, along with their leader's pid. The view then groups
> the worker entries under the matching leader's pid and shows only the
> leader rows, so no new shared memory is needed.
Right, that is what I am thinking also.
> One thing to note is that pg_stat_get_progress_info('VACUUM') itself
> would still return the worker rows, and the grouping happens in the
> pg_stat_progress_vacuum view instead.
Yes, that would be the best way. Do the aggregation on the SQL level
using array_agg.
> While I'm here, in the "vacuuming indexes" phase I also want to report
> the total index pages to scan and the pages scanned so far, for the
> index currently being vacuumed. On a large index this phase can run
> for a long time with no way to tell whether it's making progress.
This was brought up when the "index progress" columns were being worked on, and
knowing the total was not possible for all index types [1]
> Does this direction sound reasonable, or do you see a reason to prefer
> a different approach?
Yes, I think the SQL level aggregation is sane.
[1] https://www.postgresql.org/message-id/CAH2-Wz%3D3JGBty%3D3tXoBoEYYwQNd7fXJuN9oPcnBAj3JYroBv3w%40mail.gmail.com
--
Sami Imseih
Amazon Web Services (AWS)
