Hi Amit-san!
Thanks for your comments!
> I have looked at the patch and here are some comments.
>
> I think include_children and current_relid are not enough to
> understand the progress of analyzing inheritance trees, because even
> with current_relid being updated, I can't tell how many more there
> will be. I think it'd be better to show the total number of children
> and the number of children processed, just like
> pg_stat_progress_create_index does for partitions. So, instead of
> include_children and current_relid, I think it's better to have
> child_tables_total, child_tables_done, and current_child_relid, placed
> last in the set of columns.
Ah, I understood.
I'll check pg_stat_progress_create_index does for partitions,
and will create a new patch. :)
Related to the above,
I wonder whether we need the total number of ext stats on
pg_stat_progress_analyze or not. As you might know, there is the same
counter on pg_stat_progress_vacuum and pg_stat_progress_cluster.
For example, index_vacuum_count and index_rebuild_count.
Would it be added to the total number column to these views? :)
> Also, inheritance tree stats are created *after* creating single table
> stats, so I think that it would be better to have a distinct phase
> name for that, say "acquiring inherited sample rows". In
> do_analyze_rel(), you can select which of two phases to set based on
> whether inh is true or not. For partitioned tables, the progress
> output will immediately switch to this phase, because partitioned
> table itself is empty so there's nothing to do in the "acquiring
> sample rows" phase.
>
> That's all for now.
Okay! I'll also add the new phase "acquiring inherited sample rows" on
the next patch. :)
Thanks,
Tatsuro Yamada
