Re: Ideas about a better API for postgres_fdw remote estimates

Greetings,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Mon, Aug 31, 2020 at 12:19:52PM -0400, Stephen Frost wrote:
> > * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> > > 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.
>
> I am not sure what point you are trying to make, but if it had enough
> value, wouldn't people work on it, or are you saying that it had enough
> value, but people didn't realize it, so didn't work on it? I guess I
> can see that. For me, it was the maintenance burden that always scared
> me from getting involved since it would be the rare case where
> pg_upgrade would have to be modified for perhaps every major release.

The point I was making was that it has value and people did realize it
but there's only so many resources to go around when it comes to hacking
on PG and therefore it simply hasn't been done yet.

There's a big difference between "yes, we all agree that would be good
to have, but no one has had time to work on it" and "we don't think this
is worth having because of the maintenance work it'd require." The
latter shuts down anyone thinking of working on it, which is why I said
anything.

> > 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.
>
> Yep, see above. The problem isn't mostly the initial patch, but someone
> who is going to work on it and test it for every major release,
> potentially forever. Frankly, this is a pg_dump feature, rather than
> something pg_upgrade should be doing, because not having to run ANALYZE
> after restoring a dump is also a needed feature.

I tend to agree with it being more of a pg_dump issue- but that also
shows that your assessment above doesn't actually fit, because we
definitely change pg_dump every release. Consider that if someone wants
to add some new option to CREATE TABLE, which gets remembered in the
catalog, they have to make sure that pg_dump support is added for that.
If we added the statistics export/import to pg_dump, someone changing
those parts of the system would also be expected to update pg_dump to
manage those changes, including working with older versions of PG.

Thanks,

Stephen