|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2016/12/07 20:23, Etsuro Fujita wrote:
> 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
>>>> outermost query gets deparsed before FROM clause. For later we call
>>>> deparseRangeTblRef(), which builds the tlist. So, while deparsing
>>>> clause, we do not have tlist to build from. In that case, I guess,
>>>> we have
>>>> 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
>>>> there. Then in deparseRangeTblRef() assert that there's a tlist in
>>>> and use it to build the SELECT clause of subquery. That way, we don't
>>>> tlist unless it's needed and also use the same tlist for all searches.
>>>> 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
>>> for the exact comparison. I think it would be much easier to implement
>> 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  point
>> #15, further elaborated in 
> 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.
I implemented that to address your concern:
* deparseRangeTblRef uses the tlist created as above, to build the
SELECT clause of the subquery. (You said "Then in deparseRangeTblRef()
assert that there's a tlist in fpinfo", but the tlist may be empty, so I
didn't add any assertion to that function.)
* get_relation_column_alias_ids uses tlist_member with the tlist.
I also addressed the comments #1, #2 and #3 in . For #1, I added
"LIMIT 10" to the query. Attached is the new version of the patch.
* As discussed before, renamed grouped_tlist in fpinfo to "tlist" and
used it to store the tlist created as above.
* Also, renamed SS_REL_ALIAS_PREFIX to SUBQUERY_REL_ALIAS_PREFIX
(Likewise for SS_COL_ALIAS_PREFIX).
* Relocated some functions.
* Revised comments a little bit.
|Next Message||Kohei KaiGai||2016-12-08 13:00:30||Re: varlena beyond 1GB and matrix|
|Previous Message||Etsuro Fujita||2016-12-08 12:04:57||Re: Push down more full joins in postgres_fdw|