pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Andrei Lepikhov <lepihov@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Sabino Mullane <htamfids@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Alexander Lakhin <exclusion@gmail.com>
Subject: Re: Correction of RowMark Removal During Sel-Join Elimination
Date: Mon, 1 Sep 2025 11:23:59 +0200
Message-ID: <4901f7de-c883-4af3-a3f0-345ba0e27edf@gmail.com> (raw)
In-Reply-To: <CAMbWs4-ObbGGyQeamevzhcgVoDEiUTJQC9-EKVeZqRFs05McdQ@mail.gmail.com>
References: <18c6bd6c-6d2a-419a-b0da-dfedef34b585@gmail.com>
	<CAKAnmmJzSGzTRaLATNZPErByO3-j6MwsK--qPSiRLJi4kB05HQ@mail.gmail.com>
	<e7c8173c-91be-41a3-a390-2ca84fbc5147@gmail.com>
	<CAPpHfdsP_abX5hjnxiRJ6guU9P1FH4EdNTMksoGD05tTG1o9vA@mail.gmail.com>
	<9b10b847-067e-45cf-bbf7-7802b6303fc0@gmail.com>
	<CAPpHfdt+bGtrBT8FnPyiP0hq30p0_dUR192RK7TO2LJdTjHnsQ@mail.gmail.com>
	<CAPpHfdt--907hhUzKRJiBce0_e1NUmU6QFnUAtdag4vWzu62eg@mail.gmail.com>
	<CAPpHfdvAHm59MMagJchKM6ECqr7ompQfdD32MkZz9DD9kXqXAA@mail.gmail.com>
	<CAMbWs49pvuAi0JpgfpYcN1cORmrHVX5fHy4rRKuPZ2ekoempJg@mail.gmail.com>
	<CAMbWs49K+N_naHTHSerYFcUD8oRcrKG+1coAHG_sjRdXg3iXtQ@mail.gmail.com>
	<CAPpHfds95Y3DGESNwpo=dhpcnM-fECMhiTXj_KTSXmWbgC2BtA@mail.gmail.com>
	<CAMbWs4-ObbGGyQeamevzhcgVoDEiUTJQC9-EKVeZqRFs05McdQ@mail.gmail.com>

On 31/8/2025 03:03, Richard Guo wrote:
> On Sun, Aug 31, 2025 at 9:50 AM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>> On Sun, Aug 31, 2025 at 2:51 AM Richard Guo <guofenglinux@gmail.com> wrote:
>>> I think it's better to push this patch sooner rather than later, as
>>> multiple people have encountered the issue in different ways.  I'll go
>>> ahead and push 0001 from my patch set shortly.
> 
>> I see.  You're much farther than I'm.  Please, go ahead pushing this.
> 
> Done.
Hmm, is this enough? As I see, it is a typical pattern: after 
deserialisation by the stringToNode function, Postgres attempts to call 
eval_const_expressions. See, for example, RelationGetIndexExpressions.

That seems strange, because who knows what the entry No.1 is and how 
constant evaluation over this relation influences the expression tree. 
Perhaps it would be beneficial to refactor all this logic? Maybe go 
further and, before storing any relation constraint to the system 
catalogue, replace varno with something like 'UNDEF_VAR (-5)'?

I thought about why it was designed that way. Commit eabc714 shows that 
at that time, the eval_const_expressions didn't touch PlannerInfo data 
at all. Currently, it requires query structures in some cases, 
particularly in prosupport functions, which necessitates having correct 
relation references.

-- 
regards, Andrei Lepikhov





view thread (16+ messages)  latest in thread

Message-ID: <4901f7de-c883-4af3-a3f0-345ba0e27edf@gmail.com>
Permalink:  ../4901f7de-c883-4af3-a3f0-345ba0e27edf@gmail.com/
Also on:    postgresql.org/message-id/4901f7de-c883-4af3-a3f0-345ba0e27edf@gmail.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: lepihov@gmail.com, guofenglinux@gmail.com, aekorotkov@gmail.com, tgl@sss.pgh.pa.us, htamfids@gmail.com, pgsql-hackers@lists.postgresql.org, exclusion@gmail.com
  Subject: Re: Correction of RowMark Removal During Sel-Join Elimination
  In-Reply-To: <4901f7de-c883-4af3-a3f0-345ba0e27edf@gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox