Re: FDW API: don't like the EXPLAIN mechanism

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: FDW API: don't like the EXPLAIN mechanism
Дата
Msg-id 23437.1298174866@sss.pgh.pa.us
обсуждение исходный текст
Ответ на FDW API: don't like the EXPLAIN mechanism  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: FDW API: don't like the EXPLAIN mechanism  (Robert Haas <robertmhaas@gmail.com>)
Re: FDW API: don't like the EXPLAIN mechanism  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
I wrote:
> ... I think we should drop
> FdwPlan.explainInfo and instead define an additional callback function
> that is called by EXPLAIN to produce the extra data for EXPLAIN to
> display.  This function could have access to the EXPLAIN options as well
> as (in ANALYZE mode) the final state of the execution node, so it could
> tailor its output appropriately.

My initial idea was to define the new callback function with signature

char *
ExplainForeignScan (ForeignScanState *node,                   ExplainState *es);

and stick to pretty much the functionality implemented in the submitted
patch, ie, you could expect to get output looking like this:
Foreign Scan on public.agg_csv  FDW Info: file="@abs_srcdir@/data/agg.csv", size=46

However, it occurs to me that as long as we're passing the function the
ExplainState, it has what it needs to add arbitrary EXPLAIN result
fields.  Although it could do this the hard way, we could make it a lot
easier by exporting the ExplainProperty<Type> functions.  Then it'd be
possible to produce output like
Foreign Scan on public.agg_csv  Foreign File: @abs_srcdir@/data/agg.csv  Foreign File Size: 46

which seems a whole lot nicer than the current design.  In this scheme
the callback function would just be declared to return void.

Anybody have an objection to doing it like that?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Sync Rep v17
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Sync Rep v17