Re: Inconsistent RestrictInfo serial numbers
От | Ashutosh Bapat |
---|---|
Тема | Re: Inconsistent RestrictInfo serial numbers |
Дата | |
Msg-id | CAExHW5vL72SWj_f7O0ARS=F2Q9Rz9S9w4vCm8D6+akOA3jDj1A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inconsistent RestrictInfo serial numbers (Richard Guo <guofenglinux@gmail.com>) |
Ответы |
Re: Inconsistent RestrictInfo serial numbers
|
Список | pgsql-hackers |
On Wed, Oct 9, 2024 at 7:45 AM Richard Guo <guofenglinux@gmail.com> wrote: > > On Tue, Oct 8, 2024 at 9:02 PM Ashutosh Bapat > <ashutosh.bapat.oss@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. > > > 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 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? -- Best Wishes, Ashutosh Bapat
В списке pgsql-hackers по дате отправления: