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

>
>
>> For every relation that is deparsed as a subquery, we will create a
>> separate context. Each such context will have an array described
>> above. This array will contain the targetlist and aliases for all the
>> relations, covered by that relation, that are required to be deparsed
>> as subqueries. These arrays bubble up to topmost relation that is not
>> required to be deparsed as subquery. When a relation is required to be
>> deparsed as a subquery, its immediate upper relation sets the alias
>> and targetlist chosen for that relation at all the indexes
>> corresponding to all the base relations covered by that relation.
>
>
> Thanks for the explanation!
>
>> For
>> example, let's assume that a relation (1, 2, 3) is required to be
>> deparsed as subquery for an immediate upper relation (1, 2, 3, 4, 5)
>> (thus the other joining relation being (4,5)). While deparsing for
>> relation (1,2,3,4,5), the context will contain a 5 element array, with
>> positions 1, 2, 3 filled by same targetlist and alias whereas
>> positions 4 and 5 will not be filled as those relations are not
>> deparsed as subqueries.
>
>
> Sorry, I don't understand this.  In that case, the immediate upper relation
> (1, 2, 3, 4, 5) would need to fill the targetlist and aliases for *the join
> relation (1, 2, 3) somewhere*, not the targetlist and aliases for each of
> the component relations 1, 2, and 3, because the join relation is deparsed
> as a subquery.  Maybe I'm missing something, though.

The description above does not specify "targetlist and alias" for each
of (1, 2, 3). The array in the context will have positions 1, 2, 3
filled with *same* alias and targetlist which is derived from relation
(1, 2, 3).

>
>> Let's assume in relation (1, 2, 3), (1, 3) in
>> turn requires subquery but (2) does not. Thus the context created
>> while deparsing (1, 2, 3) will have a 3 element array with positions 1
>> and 3 containing the same targetlist and alias, where as position 2
>> will be empty.
>
>
>> When deparsing a Var node with varno = N and varattno =
>> m, if the nth position in the array in the context is empty, that Var
>> node will be deparsed as rN.<column name>.
>
>
> What happens when deparsing eg, a Var with varno = 2 at the topmost relation
> (1, 2, 3, 4, 5)?  The second position of the array is empty, but the join
> relation (1, 2, 3) is deparsed as a subquery, so the Var should be deparsed
> as an alias of an output column of the subquery at the topmost relation, I
> think.

position 2 will not be empty, it will be filled by the alias and
targetlist derived from relation (1, 2, 3).

>
>> But if that position is has
>> alias sZ, then we search for that Var node in the targetlist and if
>> it's found at kth position in the targetlist, we will deparse it as
>> sZ.ck. The search in the targetlist can be performed using
>> tlist_member, and then fetching the position by TargetEntry::resno.
>
>
>> This does not require any recursion and thus saves stack space and
>> some CPU cycles required for recursion.
>
>
> Is that true?

Yes, unless you explain why is that false.

>
>> some CPU cycles required for recursion. I guess, the arrays need to be
>> computed only once for any relation when the query for that relation
>> is deparsed the first time.
>
>
> Does this algorithm extend to the case where we consider paths for every
> join order?

Yes, if we store the information about which of relations need
subquery and which don't for every join order.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company