On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > On 2017/01/05 21:11, Ashutosh Bapat wrote: >> >> On Thu, Jan 5, 2017 at 5:14 PM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp> wrote: >>> >>> On 2017/01/03 17:28, Ashutosh Bapat wrote: >>>> >>>> In build_subquery_tlists(), why don't we handle base relations? >>>> + if (foreignrel->reloptkind != RELOPT_JOINREL) >>>> + return; > > >>> The reason for that is we don't need to handle the baserel cases; the >>> tlist >>> for a base relation, if needed, would be created while recursing into a >>> join >>> relation that joins the base relation to other base/join relation. > > >> Right. Sorry, I misunderstood the code. May be a comment would help. > > > Will add the comment. > >>>> Also, in this function, if fpinfo->tlist is already set, why do we want >>>> to >>>> build it again? > > >>> When this function gets called, fpinfo->tlist isn't set for any base or >>> join >>> relation that needs to build the tlist, so we always need to build it for >>> each such relation. > > >> IIUC, for a relation with use_remote_estimates we will deparse the >> query twice and will build the targetlist twice. > > > That's right. We could avoid the duplicate work the way you proposed, but I > was thinking to leave that for another patch. Should we do that in this > patch?
If you are agree that the change is needed, it's better to do it in this patch itself if we can, instead of a one liner patch. > >>>> In build_tlist_to_deparse(), if fpinfo->tlist for the given relation is >>>> set, we >>>> should just return it rather than constructing it again. > > >>> In that function we wouldn't have such cases for base or join relations >>> needing the tlist. > > >> Same explanation as above. > > > Will revise if it's better to do that in this patch. Thanks. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers