Re: progress report for ANALYZE
От | Tatsuro Yamada |
---|---|
Тема | Re: progress report for ANALYZE |
Дата | |
Msg-id | 86313061-3ee4-ad23-fe25-a87d9273260d@nttcom.co.jp_1 обсуждение исходный текст |
Ответ на | Re: progress report for ANALYZE (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: progress report for ANALYZE
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: