Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes:
> (2012/03/09 14:00), Tom Lane wrote:
>> Attached is a draft patch for that.
> 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.
> 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 for a little bit
about trying to give different names to all four of the fdw private
fields (RelOptInfo, Path, Plan, PlanState) but it's not obvious what
naming rule to use, and at least the last two of those can't be changed
without breaking existing FDW code.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
