Re: Clarifying/rationalizing Vars' varno/varattno/varnoold/varoattno

On Fri, Dec 20, 2019 at 11:13 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The alternatives that seem plausible at this point are
>
> (1) Create some sort of wrapper node indicating "the contents of this
> expression might be replaced by NULL". This is basically what the
> planner's PlaceHolderVars do, so maybe we'd just be talking about
> introducing those at some earlier stage.
>
> (2) Explicitly mark Vars as being nullable by some outer join. I think
> we could probably get this down to one additional integer field in
> struct Var, so it wouldn't be too much of a penalty.
>
> The wrapper approach is more general since you can wrap something
> that's not necessarily a plain Var; but it's also bulkier and so
> probably a bit less efficient. I'm not sure which idea I like better.

I'm not sure which is better, either, although I would like to note in
passing that the name PlaceHolderVar seems to me to be confusing and
terrible. It took me years to understand it, and I've never been
totally sure that I actually do. Why is it not called
MightBeNullWrapper or something?

If you chose to track it in the Var, maybe you could do better than to
track whether it might have gone to NULL. For example, perhaps you
could track the set of baserels that are syntactically below the Var
location and have the Var on the nullable side of a join, rather than
just have a Boolean that indicates whether there are any. I don't know
whether the additional effort would be worth the cost of maintaining
the information, but it seems like it might be.

> With either approach, we could either make parse analysis inject the
> nullability markings, or wait to do it in the planner. On a purely
> abstract system structural level, I like the former better: it is
> exactly the province of parse analysis to decide what are the semantics
> of what the user typed, and surely what a Var means is part of that.
> OTOH, if we do it that way, the planner potentially has to rearrange the
> markings after it does join strength reduction; so maybe it's best to
> just wait till after that planning phase to address this at all.
>
> Any thoughts about that?

Generally, I like the idea of driving this off the parse tree, because
it seems to me that, ultimately, whether a Var is *potentially*
nullable or not depends on the query as provided by the user. And, if
we replan the query, these determinations don't change, at least as
long as they are only driven by the query syntax and not, say,
attisnull or opclass details. It would be nice not to redo the work
unnecessarily. However, that seems to require some way of segregating
the information we derive as a preliminary and syntactical judgement
from subsequent inferences made during query planning, because the
latter CAN change during replanning.

It might be useful 'Relids' with each Var rather than just 'bool'. In
other words, based on where the reference to the Var is in the
original query text, figure out the set of joins where (1) the Var is
syntactically above the join and (2) on the nullable side, and then
put the relations on the other sides of those joins into the Relids.
Then if you later determine that A LEFT JOIN B actually can't make
anything go to null, you can just ignore the presence of A in this set
for the rest of planning. I feel like this kind of idea might have
other applications too, although I admit that it also has a cost.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company