> > >> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
