On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
> (2014/07/01 15:13), Ashutosh Bapat wrote: > >> On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> > > 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
