(2012/03/09 23:48), Tom Lane wrote: > Etsuro Fujita<fujita.ets...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
