I thought about the strategy below in the past few days, and think it
is better because it uses less cycles to get the same answer. IIUC, the
related structs should be created during / after deconstruct_jointree rather
than join_search_xx stage.
> The schemes I've been toying with tend to look
Hi Ashutosh:
Nice to see you again!
On Tue, May 17, 2022 at 8:50 PM Ashutosh Bapat
wrote:
> On Sun, May 15, 2022 at 8:41 AM Andy Fan wrote:
>
> >
> > The var in RelOptInfo->reltarget should have nullable = 0 but the var in
> > RelOptInfo->baserestrictinfo should have nullable = 1; The beau
Hi Tom:
Thanks for your attention!
On Wed, May 18, 2022 at 1:25 AM Tom Lane wrote:
> Andy Fan writes:
> > notnulls discussion is forked from UniqueKey stuff, you can see the
> > attachment
> > for the UnqiueKey introduction. Tom raised his opinion to track the
> > nullability
> > inside Var[1]
Andy Fan writes:
> notnulls discussion is forked from UniqueKey stuff, you can see the
> attachment
> for the UnqiueKey introduction. Tom raised his opinion to track the
> nullability
> inside Var[1][2][3], this thread would start from there based on my
> understanding.
I'm pretty certain that I
On Sun, May 15, 2022 at 8:41 AM Andy Fan wrote:
>
> The var in RelOptInfo->reltarget should have nullable = 0 but the var in
> RelOptInfo->baserestrictinfo should have nullable = 1; The beauty of this
> are: a). It can distinguish the two situations perfectly b). Whenever we want
> to know the n
notnulls discussion is forked from UniqueKey stuff, you can see the
attachment
for the UnqiueKey introduction. Tom raised his opinion to track the
nullability
inside Var[1][2][3], this thread would start from there based on my
understanding.
Generally tracking the null attributes inside Var would
