Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Sat, Aug 29, 2020 at 12:50:59PM -0400, Tom Lane wrote: > > Stephen Frost <sfr...@snowman.net> writes: > > > Isn't this going to create a version dependency that we'll need to deal > > > with..? What if a newer major version has some kind of improved ANALYZE > > > command, in terms of what it looks at or stores, and it's talking to an > > > older server? > > > > Yeah, this proposal is a nonstarter unless it can deal with the remote > > server being a different PG version with different stats. > > > > Years ago (when I was still at Salesforce, IIRC, so ~5 years) we had > > some discussions about making it possible for pg_dump and/or pg_upgrade > > to propagate stats data forward to the new database. There is at least > > one POC patch in the archives for doing that by dumping the stats data > > wrapped in a function call, where the target database's version of the > > function would be responsible for adapting the data if necessary, or > > maybe just discarding it if it couldn't adapt. We seem to have lost > > interest but it still seems like something worth pursuing. I'd guess > > that if such infrastructure existed it could be helpful for this. > > I don't think there was enough value to do statistics migration just for > pg_upgrade, but doing it for pg_upgrade and FDWs seems like it might > have enough demand to justify the required work and maintenance.
Not sure that it really matters much, but I disagree with the assessment that there wasn't enough value to do it for pg_upgrade; I feel that it just hasn't been something that's had enough people interested in working on it, which isn't the same thing. If a good patch showed up tomorrow, with someone willing to spend time on it, I definitely think it'd be something we should include even if it's just for pg_upgrade. A solution that works for both pg_upgrade and the postgres FDW would be even better, of course. Thanks, Stephen
signature.asc
Description: PGP signature
