On Wed, Oct 9, 2024 at 9:30 PM Ashutosh Bapat <ashutosh.bapat....@gmail.com> wrote: > On Wed, Oct 9, 2024 at 7:45 AM Richard Guo <guofengli...@gmail.com> wrote: > > On Tue, Oct 8, 2024 at 9:02 PM Ashutosh Bapat > > <ashutosh.bapat....@gmail.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
