I've been poking at the FDW stuff and file_fdw, and I find myself
dissatisfied with the way that the EXPLAIN support is designed,
namely that we have to compute a string at plan time to be displayed
by EXPLAIN. There are a couple of problems with that:
1. The explainInfo string is useless overhead during a normal query.
2. There is no way to vary the display depending on EXPLAIN options such
as VERBOSE and COSTS OFF.
It seems fairly obvious to me that there might be scope for showing
more info in VERBOSE mode. But even more to the point, the current
regression test's example output:
EXPLAIN (VERBOSE, COSTS FALSE) SELECT * FROM agg_csv;Foreign Scan on public.agg_csv Output: a, b Foreign Plan:
file="@abs_srcdir@/data/agg.csv",size=46
is extremely bogus. COSTS OFF ought to suppress highly-volatile details
like the file size. To stick with this design, we'd have to have a
convention that explainInfo never shows any more data than would be
appropriate in COSTS OFF mode.
And then there's
3. There is no way to report actual inside-the-FDW execution stats in
EXPLAIN ANALYZE mode.
So this seems very far short of satisfactory. 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.
BTW, another thing that strikes me as poorly done in the file_fdw code
is that it gathers up all the options of the foreign table, server, and
wrapper at plan time, and stores those in the plan, and uses that
information at runtime. What happens if the options change underneath
a prepared plan?
regards, tom lane
