Re: Inconsistent RestrictInfo serial numbers

On Wed, Oct 9, 2024 at 9:30 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> On Wed, Oct 9, 2024 at 7:45 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> > On Tue, Oct 8, 2024 at 9:02 PM Ashutosh Bapat
> > <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
> > > But I don't see any relation specific information being
> > > considered while deciding whether the clause is constant false.
> >
> > Isn't rel->notnullattnums relation specific information? We need this
> > information to decide if a Var cannot be NULL.
>
> I am talking about restriction_is_always_false() being called from
> add_base_clause_to_rel(). The later doesn't pass the given relid or
> the corresponding rel to the first. So restriction_is_always_false()
> is independent of relid passed to add_base_clause_to_rel() and thus
> restriction_is_always_false() being called from outside (say caller of
> add_base_clause_to_rel()) will have same result for the same
> RestrictInfo.

I see what you meant now. You're right that the result of
restriction_is_always_true/false is independent of the relid.
However, I still don't think it's a good idea to move it elsewhere
because: 1) we need the relid to determine whether the relation is an
inheritance parent table, as we must avoid this type of simplification
for those tables; 2) I recall there was a discussion during the work
on commit b262ad440 about potentially extending the simplification
logic in the future to consider the relation's constraints.

> > > So may
> > > be we should do this processing elsewhere and replace the original
> > > clause itself?
> >
> > I’m not sure about this. Different versions of the same qual clause
> > can lead to different conclusions about whether it can be reduced to
> > constant-FALSE.
>
> Can you please provide an example?

I think the query I provided in my initial email serves as an example.
To quote what I said there:

"
In the query above, the has_clone version of qual 't1.a is null' would
be reduced to constant-FALSE, while the is_clone version would not.
"

> > I don't think it is possible to replace the original
> > clause; we need to do this processing on a version-by-version basis.
> >
>
> Either way, each version will be represented by only one RestrictInfo.
> Why can't we replace that version instead of creating a new
> RestrictInfo?

Sure we can do that. However, I find that manually altering a
well-formed RestrictInfo's clause (along with its left_relids,
right_relids, clause_relids, num_base_rels, etc.) seems too
hacky to me.

Thanks
Richard