On 2025-Jul-21, Jiří Kavalík wrote: > I noticed that but not sure if it is targeting v19?
It is -- I'm working on that patch. > I hoped to make the change as small as possible, but if it would > collide with the refactoring then it makes sense to separate the > functionality. I think from the users' point of view it makes little sense to report the progress of ALTER TABLE rewriting in the same view as CLUSTER. This is irrespective of the implementation difficulty. I mean, as a user trying to monitor an operation, why would I be querying pg_stat_progress_cluster? That's just weird. On the other hand, ALTER TABLE has a need to report whether it's rewriting the table or just reading it to recheck or validate constraints. If you try to cram that bit of state in the CLUSTER report, it's going to look strange, because it doesn't make sense for CLUSTER. I think the distinction is rather important: for example if you're just checking constraints, you don't need to rebuild indexes. This is information that the user would be really happy to know. In any case, having a separate progress.h definition isn't really all that much extra work: it's just one more view and a few #defines to give symbolic names to each counter. Another point that might be worth keeping in mind is ALTER TABLE's recursion mechanism for inheritance and partitioning. As a user I imagine I would like to know how far we are not just in processing the current relation, but also how many children are done and how many are still left. Also worth keeping in mind: some AT subcommands use the "standard" recursion mechanism that simply adds extra subcommands to the queue for each child relation, whereas other AT subcommands implement recursion at execution time. Those work very differently. What about multi-command ALTER TABLE? I think this is easy because we preprocess the command to collect a list of actions to execute, and then rnu a single check/rewrite scan on each table. So you may not need to do anything special. But it's worth thinking about. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "People get annoyed when you try to debug them." (Larry Wall)
