Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > If we go down that route, since this makes a pretty serious difference > > in terms of what the user has to deal with post-pg_upgrade, I'd suggest > > we require an additional option for the user to pass when stats aren't > > going to be migrated, so they are aware of that. > > -1 ... you are forgetting that a lot of systems wrap pg_upgrade in some > sort of vendor-supplied upgrade script. Nanny switches don't help; > the vendors will just start passing them automatically.
That really depends on the packagers. > > Of course, this might end up having an entirely different effect: it > > might mean that we're suddenly a lot shier about changing the stats in a > > backwards-incompatible way, just as we now are basically stuck with the > > existing on-disk heap format.. > > Yeah, there's that. But the rate of change in pg_statistic hasn't been > *that* large. Alvaro might be right that we can design some transmission > procedure that allows stats to be forward-migrated when compatible and > dropped when not. Well, if it's dropped, I think we need to make sure that users are aware of that going in and that's why I was suggesting a switch. If you've got a better idea for that, great, but having certain pg_upgrade migrations require running ANALYZE and some migrations not require it is something we need to make users *very* clear about. No, I don't think a note in the release notes is really enough.. Thanks! Stephen
signature.asc
Description: Digital signature