Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
> On Thu, Feb 11, 2021 at 8:22 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> writes:
>>> Can this information be part of PathTarget structure and hence part of
>>> RelOptInfo::reltarget, so that it can be extended to join, group and
>>> other kinds of RelOptInfo in future?

>> Why would that be better than keeping it in RelOptInfo?

> We have all the expressions relevant to a given relation (simple,
> join, group whatever) in Pathtarget. We could remember notnullness of
> attributes of a simple relation in RelOptInfo. But IMO non/nullness of
> the TLEs of a relation is more useful that attributes and thus
> associate those in the PathTarget which is used to produce TLEs. That
> way we could use this infra in more general ways.

That argument seems nearly vacuous to me, because for pretty much any
expression that isn't a base-relation Var, the answer will have to be
"don't know". Meanwhile, there are clear costs to keeping such info
in PathTarget, namely having to copy it around. Another issue with
keeping it in PathTarget is that I'm not convinced it'll be readily
available where you need it: most places that would be interested in
making such proofs are only looking at expression trees.

Now there is one angle that *might* become easier if the info were in
PathTarget, namely that it could be simpler and more reliable to mark
nullable output columns of an outer join as being nullable (even if
they came from not-null base columns). However, as I've muttered
about elsewhere, I'd prefer to deal with that can of worms by altering
the representation of the Vars themselves. Again, if you're looking
at a WHERE clause, it's not real clear how you would find a relevant
PathTarget.

regards, tom lane