BTW, why aren't you using the tlist passed to this function? I guess create_scan_plan() passes tlist after processing it, so that should be used rather than rel->reltargetlist.
I think that that would be maybe OK, but I think that it would not be efficient to use the list to compute attrs_used, because the tlist would have more information than rel->reltargetlist in cases where the tlist is build through build_physical_tlist().
In that case, we can call build_relation_tlist() for foreign tables.
Do you mean build_physical_tlist()?
Sorry, I meant build_path_tlist() or disuse_physical_tlist() whichever is appropriate.
We may want to modify use_physical_tlist(), to return false, in case of foreign tables. BTW, it does return false for inheritance trees.
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.
Thanks,
Best regards, Etsuro Fujita
--
Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
