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

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: FDW API: don't like the EXPLAIN mechanism
Date: 2011-02-20 00:01:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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:

 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

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


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-02-20 00:13:13
Subject: Re: Update PostgreSQL shared memory usage table for 9.0?
Previous:From: Bruce MomjianDate: 2011-02-20 00:00:30
Subject: Re: UTF16 surrogate pairs in UTF8 encoding

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