Re: Push down more full joins in postgres_fdw

On 2016/12/07 15:39, Ashutosh Bapat wrote:

>> On 2016/11/22 18:28, Ashutosh Bapat wrote:
>>>
>>> I guess, the reason why you are doing it this way, is SELECT clause for
>>> the
>>> outermost query gets deparsed before FROM clause. For later we call
>>> deparseRangeTblRef(), which builds the tlist. So, while deparsing SELECT
>>> clause, we do not have tlist to build from. In that case, I guess, we have
>>> to
>>> build the tlist in get_subselect_alias_id() if it's not available and
>>> stick it
>>> in fpinfo. Subsequent calls to get_subselect_alias_id() should find tlist
>>> there. Then in deparseRangeTblRef() assert that there's a tlist in fpinfo
>>> and use it to build the SELECT clause of subquery. That way, we don't
>>> build
>>> tlist unless it's needed and also use the same tlist for all searches.
>>> Please
>>> use tlist_member() to search into the tlist.

I wrote:
>> This would probably work, but seems to me a bit complicated. Instead, I'd
>> like to propose that we build the tlist for each relation being deparsed as
>> a subquery in a given join tree, right before deparsing the SELECT clause in
>> deparseSelectStmtForRel, if is_subquery is false and lower_subquery_rels
>> isn't NULL, and store the tlist into the relation's fpinfo. That would
>> allow us to build the tlist only when we need it, and to use tlist_member
>> for the exact comparison. I think it would be much easier to implement
>> that.

> IIRC, this is inline with my original proposal of creating tlists
> before deparsing anything. Along-with that I also proposed to bubble
> this array of tlist up the join hierarchy to avoid recursion [1] point
> #15, further elaborated in [2]
>
> [1] https://www.postgresql.org/message-id/ad449b25-66ee-4c06-568c-0eb2e1bef9f9%40lab.ntt.co.jp
> [2] https://www.postgresql.org/message-id/CAFjFpRcn7%3DDNOXm-PJ_jVDqAmghKVf6tApQC%2B_RgMZ8tOPExcA%40mail.gmail.com
>
> We seem to be moving towards that solution, but as discussed we have
> left it to committer's judgement.

My proposal here would be a bit different from what you proposed; right
before deparseSelectSql in deparseSelectStmtForRel, build the tlists for
relations present in the given jointree that will be deparsed as
subqueries, by (1) traversing the given jointree and (2) applying
build_tlist_to_deparse to each relation to be deparsed as a subquery and
saving the result in that relation's fpinfo. I think that would be
implemented easily, and the overhead would be small.

Best regards,
Etsuro Fujita