On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
> (2014/06/30 20:17), Ashutosh Bapat wrote: > >> On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote: >> > > (2014/06/30 17:47), Ashutosh Bapat wrote: >> > > 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
