Re: Ideas about a better API for postgres_fdw remote estimates

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: Ideas about a better API for postgres_fdw remote estimates
Date: 2020-08-31 16:19:52
Message-ID: 20200831161952.GQ29590@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Sat, Aug 29, 2020 at 12:50:59PM -0400, Tom Lane wrote:
> > Stephen Frost <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2020-08-31 16:32:00 Re: list of extended statistics on psql
Previous Message Alvaro Herrera 2020-08-31 16:18:09 Re: list of extended statistics on psql