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 1301903.1593970603@sss.pgh.pa.us
Whole thread Raw
In response to Re: Ideas about a better API for postgres_fdw remote estimates  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Ideas about a better API for postgres_fdw remote estimates
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> * Rather than adding a core-server feature, the remote-end part of the new
>> API should be a function installed by an extension (either postgres_fdw
>> itself, or a new extension "postgres_fdw_remote" or the like).

> I'm trying to figure out why it makes more sense to use
> 'postgres_fdw_support(query text)', which would still do parse/plan and
> return EXPLAIN-like data, rather than having:

> EXPLAIN (FORMAT JSON, FDW true) query ...

I see a couple of reasons not to do it like that:

1. This is specific to postgres_fdw.  Some other extension might want some
other data, and different versions of postgres_fdw might want different
data.  So putting it into core seems like the wrong thing.

2. Wedging this into EXPLAIN would be quite ugly, because (at least
as I envision it) the output would have just about nothing to do with
any existing EXPLAIN output.

3. We surely would not back-patch a core change like this.  OTOH, if
the added infrastructure is in an extension, somebody might want to
back-patch that (even if unofficially).  This argument falls to the
ground of course if we're forced to make any core changes to be able
to get at the data we need; but I'm not sure that will be needed.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Default gucs for EXPLAIN
Next
From: Stephen Frost
Date:
Subject: Re: Ideas about a better API for postgres_fdw remote estimates