Re: Ideas about a better API for postgres_fdw remote estimates - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Ideas about a better API for postgres_fdw remote estimates
Date
Msg-id 3565504.1598719859@sss.pgh.pa.us
Whole thread Raw
In response to Ideas about a better API for postgres_fdw remote estimates  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Ideas about a better API for postgres_fdw remote estimates  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
List pgsql-hackers
Stephen Frost <sfrost@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.

> When I was considering the issue with ANALYZE and FDWs, I had been
> thinking it'd make sense to just change the query that's built in
> deparseAnalyzeSql() to have a TABLESAMPLE clause, but otherwise run in
> more-or-less the same manner as today.

+1, that seems like something worth doing in any case, since even if
we do get somewhere with the present idea it would only work for new
remote servers.  TABLESAMPLE would work pretty far back (9.5,
looks like).

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Clang UndefinedBehaviorSanitize (Postgres14) Detected undefined-behavior
Next
From: Andrey Lepikhov
Date:
Subject: Re: Ideas about a better API for postgres_fdw remote estimates