Re: Ideas about a better API for postgres_fdw remote estimates

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Ideas about a better API for postgres_fdw remote estimates
Дата
Msg-id 1301903.1593970603@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Ideas about a better API for postgres_fdw remote estimates  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Ideas about a better API for postgres_fdw remote estimates  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Default gucs for EXPLAIN
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Ideas about a better API for postgres_fdw remote estimates