Re: pgsql_fdw, FDW for PostgreSQL server

(2012/03/09 23:48), Tom Lane wrote:
> Etsuro Fujita<fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> writes:

Thank you for your answer.

>> 1. FilefdwPlanState.pages and FileFdwPlanState.ntuples seems redundant.
>> Why not use RelOptInfo.pages and RelOptInfo.tuples?
>
> I intentionally avoided setting RelOptInfo.pages because that would have
> other effects on planning (cf total_table_pages or whatever it's
> called). It's possible that that would actually be desirable, depending
> on whether you think the external file should be counted as part of the
> query's disk-access footprint; but it would take some investigation to
> conclude that, which I didn't feel like doing right now. Likewise, I'm
> not sure offhand what side effects might occur from using
> RelOptInfo.tuples, and didn't want to change file_fdw's behavior without
> more checking.

OK

>> 2. IMHO RelOptInfo.fdw_private seems confusing. How about renaming it
>> to e.g., RelOptInfo.fdw_state?
>
> Why is that better? It seems just as open to confusion with another
> field (ie, the execution-time fdw_state).

I thought the risk. However, I feel that the naming of
RelOptInfo.fdw_state is not so bad because it is used only at the query
planning time, not used along with the execution-time fdw_private. The
naming of RelOptInfo.fdw_private seems as open to confusion to me
because it would have to be used along with Path.fdw_private or
Plan.fdw_private in FDW's functions at the planning time, while I guess
that the contents of RelOptInfo.fdw_private are relatively far from the
ones of fdw_private of Path and Plan.

Best regards,
Etsuro Fujita