(2012/03/09 23:48), Tom Lane wrote:
> Etsuro Fujita<fujita.etsuro@lab.ntt.co.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
