We may want to modify use_physical_tlist(), to return false, in case of foreign tables. BTW, it does return false for inheritance trees.
Yeah, but please consider cases where foreign tables are not inheritance child rels (and any system columns are requested).
486 /* 487 * Can't do it with inheritance cases either (mainly because Append 488 * doesn't project). 489 */ 490 if (rel->reloptkind != RELOPT_BASEREL) 491 return false;
Yeah, we can call build_physical_tlist() (and do that in some cases), but if we call the function, it would generate a tlist that contains all Vars in the relation, not only those Vars actually needed by the query (ie, Vars in reltargetlist), and thus it would take more cycles to compute attr_used from the tlist than from reltargetlist. That' what I wanted to say.
Maybe I'm missing something, but what's the point of using the tlist, not reltargetlist?
Compliance with other create_*scan_plan() functions. The tlist passed to those functions is sometimes preprocessed in create_scan_plan() and some of the function it calls. If we use reltargetlist directly, we loose that preprocessing. I have not see any of create_*scan_plan() fetch the targetlist directly from RelOptInfo. It is always the one supplied by build_path_tlist() or disuse_physical_tlist() (which in turn calls build_path_tlist()) or build_physical_tlist().
Thanks,
Best regards, Etsuro Fujita
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
