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: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Push down more full joins in postgres_fdw |
Date: | 2016-11-24 07:57:20 |
Message-ID: | e4d8bf6b-2a7b-ed5f-7dfa-4c4c01466327@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016/11/24 16:46, Ashutosh Bapat wrote:
>>> Sorry. I think the current version is better than previous one. The
>>> term "subselect alias" is confusing in the previous version. In the
>>> current version, "Get the relation and column alias for a given Var
>>> node," we need to add word "identifiers" like "Get the relation and
>>> column identifiers for a given Var node".
I wrote:
>> OK, but one thing I'm concerned about is the term "relation alias" seems a
>> bit confusing because we already used the term for the alias of the form
>> "rN". To avoid that, how about saying "table alias", not "relation alias"?
>> (in which case, the comment would be something like "Get the table and
>> column identifiers for a given Var node".)
> table will be misleading as subquery can represent a join and
> corresponding alias would represent the join. Relation is better term.
But the documentation uses the word "table" for a join relation. See
7.2.1.2. Table and Column Aliases:
https://www.postgresql.org/docs/9.6/static/queries-table-expressions.html#QUERIES-TABLE-ALIASES
>> I don't think so; in the current version, we essentially deparse from and
>> search into the same object, ie, foreignrel->reltarget->exprs, since the
>> tlist created by build_tlist_to_deparse is build from the
>> foreignrel->reltarget->exprs. Also, since it is just created for deparsing
>> the relation as a subquery in deparseRangeTblRef and isn't stored into
>> fpinfo or anywhere alse, we would need no concern about creating such
>> avenues. IMO I think adding comments would be enough for this.
> build_tlist_to_depase() calls pull_var_nodes() before creating the
> tlist, whereas the code that searches does not do that. Code-wise
> those are not the same things.
You missed the point; the foreignrel->reltarget->exprs doesn't contain
any PHVs, so the tlist created by build_tlist_to_depase will be
guaranteed to be one-to-one with the foreignrel->reltarget->exprs.
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2016-11-24 08:39:27 | Re: Push down more full joins in postgres_fdw |
Previous Message | Ashutosh Sharma | 2016-11-24 07:49:07 | Re: Hash Indexes |