Re: [HACKERS] Push down more full joins in postgres_fdw - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: [HACKERS] Push down more full joins in postgres_fdw
Date
Msg-id f80fd422-b5f3-a2e1-92ac-21a1dba1dd46@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] Push down more full joins in postgres_fdw  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: [HACKERS] Push down more full joins in postgres_fdw  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
On 2017/01/03 17:28, Ashutosh Bapat wrote:

I wrote:
>> I updated the patch a bit further: simplified the function name
>> (s/build_subquery_rel_tlists/build_subquery_tlists/), and revised comments a
>> little bit.  Attached is an updated version
>> (postgres-fdw-subquery-support-v14.patch).

> Few comments

Thanks for the comments!

> 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.

> 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.

> 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.

Best regards,
Etsuro Fujita





pgsql-hackers by date:

Previous
From: Beena Emerson
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] UNDO and in-place update