Re: SQL/MED - file_fdw

On Tue, 18 Jan 2011 15:17:12 +0900
Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> wrote:

> On Sat, Jan 15, 2011 at 08:35, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp> wrote:
> > Interface of NextCopyFrom() is fixed to return HeapTuple, to support
> > tableoid without any change to TupleTableSlot.
> >
> > 3) 20110114-copy_export_HeapTupe.patch
> > This patch fixes interface of NextCopyFrom() to return results as
> > HeapTuple.
>
> I think file_fdw can return tuples in virtual tuples forms,
> and ForeignNext() calls ExecMaterializeSlot() to store tableoid.

Thanks for the comment. I've fixed file_fdw to use tts_values and
tts_isnull to receive results from NextCopyFrom, and store virtual
tuple in the slot.

Attached patch requires FDW API patches and copy_export-20110114.patch.
Please see also:
http://archives.postgresql.org/message-id/20110119002615.8316.6989961C@metrosystems.co.jp

And also cost estimation of file_fdw is simplified along your comments
below.

On Tue, 21 Dec 2010 21:32:17 +0900
Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> #3. Why do you re-open a foreign table in estimate_costs() ?
> Since the caller seems to have the options for them, you can
> pass them directly, no?
>
> In addition, passing a half-initialized fplan to estimate_costs()
> is a bad idea. If you think it is an OUT parameter, the OUT params
> should be *startup_cost and *total_cost.

In that message, you also pointed out that FDW must generate
explainInfo in every PlanRelScan call even if the planning is not for
EXPLAIN. I'll try to defer generating explainInfo until EXPLAIN
VERBOSE really uses it. It might need new hook point in expalain.c,
though.

Regards,
--
Shigeru Hanada