Re: pgsql_fdw, FDW for PostgreSQL server

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>

From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Shigeru Hanada <shigeru.hanada@gmail.com>, Albe Laurenz <laurenz.albe@wien.gv.at>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Kohei KaiGai <kaigai@kaigai.gr.jp>, Martijn van Oosterhout <kleptog@svana.org>, Hitoshi Harada <umi.tanuki@gmail.com>
Date: 2012-03-09T12:54:03Z
Lists: pgsql-hackers

Attachments

(2012/03/09 14:00), Tom Lane wrote:
> I wrote:
>> There are a couple of other points that make me think we need to revisit
>> the PlanForeignScan API definition some more, too.  ...
>> So we need to break down what PlanForeignScan currently does into three
>> separate steps.  The first idea that comes to mind is to call them
>> GetForeignRelSize, GetForeignPaths, GetForeignPlan; but maybe somebody
>> has a better idea for names?
>
> Attached is a draft patch for that.

1. FilefdwPlanState.pages and FileFdwPlanState.ntuples seems redundant. 
  Why not use RelOptInfo.pages and RelOptInfo.tuples?

2. IMHO RelOptInfo.fdw_private seems confusing.  How about renaming it 
to e.g., RelOptInfo.fdw_state?

Attached is a patch for the draft patch.

Best regards,
Etsuro Fujita