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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers