Re: Push down more full joins in postgres_fdw

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Push down more full joins in postgres_fdw
Date: 2017-01-05 11:44:51
Message-ID: f80fd422-b5f3-a2e1-92ac-21a1dba1dd46@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2017-01-05 11:51:00 Re: UNDO and in-place update
Previous Message Beena Emerson 2017-01-05 11:39:05 Re: increasing the default WAL segment size