Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group