On 2024-Nov-27, Tom Lane wrote: > I do not like the idea of breaking existing upgrade scripts, > especially not by requiring them to use a parameter that older > vacuumdb versions will reject. That makes it impossible to have a > script that is version independent. I really doubt that there is any > usability improvement to be had here that's worth that.
I was only suggesting to break it because it was said upthread that that was desirable behavior. > How about causing "--analyze-in-stages" (as currently spelled) to > be a no-op? We could keep the behavior available under some other > name. I think making it a no-op isn't useful, because people who run the old scripts will get the behavior we do not want: clobber the statistics and recompute them, losing the benefit that this feature brings. On 2024-Nov-27, Bruce Momjian wrote: > Uh, I guess we could do that, but we should emit something like > "--analyze-in-stages option ignored". I think emitting a message is not useful. It's quite possible that the output of pg_upgrade will be redirected somewhere and this will go unnoticed. Maybe the most convenient for users is to keep "vacuumdb --analyze-in-stages" doing exactly what we want to happen after pg_upgrade, that is, in 18+, only recreate the missing stats. This is because of what Corey said about messaging: many users are not going to get our message that they need to adapt their scripts, so they won't. Breaking the script would convey that message pretty quickly, but you're right that it's not very convenient. For people that want to use the old behavior of recomputing _all_ statistics not just the missing ones, we could add a different switch, or an (optional) option to --analyze-in-stages. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
