On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita
> 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
>>> for a base relation, if needed, would be created while recursing into a
>>> 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
>>>> build it again?
>>> When this function gets called, fpinfo->tlist isn't set for any base or
>>> 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
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.
The Postgres Database Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: