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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: FDW API: don't like the EXPLAIN mechanism
Date: 2011-02-20 04:07:46
Message-ID: 23437.1298174866@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-20 04:26:40 Re: Sync Rep v17
Previous Message Robert Haas 2011-02-20 03:52:32 Re: Sync Rep v17