On Wed, Nov 6, 2024 at 11:06 PM Ashutosh Bapat
wrote:
> On Wed, Nov 6, 2024 at 4:10 PM Richard Guo wrote:
> > I intend to push this patch shortly, barring any objections, so that
> > it can catch up with the next minor release (Nov. 14).
>
> I didn't get time to respond to your email and create a
On Tue, Oct 8, 2024 at 8:20 PM Richard Guo wrote:
>
> I ran into an "ERROR: variable not found in subplan target lists"
> error, which can be reproduced with the following query.
> To fix, I think we can reset the root->last_rinfo_serial counter after
> generating the additional constant-FALSE R
On Wed, Nov 6, 2024 at 4:10 PM Richard Guo wrote:
>
> On Tue, Oct 8, 2024 at 8:20 PM Richard Guo wrote:
> >
> > I ran into an "ERROR: variable not found in subplan target lists"
> > error, which can be reproduced with the following query.
>
> > To fix, I think we can reset the root->last_rinfo_s
On Fri, Oct 11, 2024 at 3:02 PM Ashutosh Bapat
wrote:
> 1. What strikes me as odd in your patch is that the last_rinfo_serial
> is reset so far away from the new clause that will be created with the
> next last_rinfo_serial OR the clause whose clones are being created.
> It either indicates anothe
On Thu, Oct 10, 2024 at 7:37 AM Richard Guo wrote:
>
>
> > > > 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 whe
On Wed, Oct 9, 2024 at 9:30 PM Ashutosh Bapat
wrote:
> On Wed, Oct 9, 2024 at 7:45 AM Richard Guo wrote:
> > On Tue, Oct 8, 2024 at 9:02 PM Ashutosh Bapat
> > wrote:
> > > But I don't see any relation specific information being
> > > considered while deciding whether the clause is constant false
On Wed, Oct 9, 2024 at 7:45 AM Richard Guo wrote:
>
> On Tue, Oct 8, 2024 at 9:02 PM Ashutosh Bapat
> 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?
On Wed, Oct 9, 2024 at 11:15 AM Andrei Lepikhov wrote:
> On 10/8/24 18:20, Richard Guo wrote:
> > To fix, I think we can reset the root->last_rinfo_serial counter after
> > generating the additional constant-FALSE RestrictInfo. Please see
> > attached.
> The approach will work, no doubt. But why
On 10/8/24 18:20, Richard Guo wrote:
To fix, I think we can reset the root->last_rinfo_serial counter after
generating the additional constant-FALSE RestrictInfo. Please see
attached.
Thanks for the job!
The approach will work, no doubt. But why are you using such a wordy
approach with save_la
On Tue, Oct 8, 2024 at 9:02 PM Ashutosh Bapat
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.
>
n a NOT NULL column might
> result in an additional constant-FALSE RestrictInfo. This can
> unexpectedly increase root->last_rinfo_serial, causing inconsistent
> RestrictInfo serial numbers across multiple clones of the same qual,
> which can confuse users of 'rinfo_serial', such as
&g
with b262ad440, an IS NULL qual on a NOT NULL column might
result in an additional constant-FALSE RestrictInfo. This can
unexpectedly increase root->last_rinfo_serial, causing inconsistent
RestrictInfo serial numbers across multiple clones of the same qual,
which can confuse users of &#
12 matches
Mail list logo
