Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ut0li-00ET2w-U0 for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Sep 2025 09:24:08 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ut0li-005Lql-7J for pgsql-hackers@arkaria.postgresql.org; Mon, 01 Sep 2025 09:24:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ut0lh-005Lqc-Tj for pgsql-hackers@lists.postgresql.org; Mon, 01 Sep 2025 09:24:06 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by makus.postgresql.org with smtp (Exim 4.96) (envelope-from ) id 1ut0lf-002oZe-2y for pgsql-hackers@lists.postgresql.org; Mon, 01 Sep 2025 09:24:05 +0000 Received: from [192.168.15.136] (unknown [80.251.191.198]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: a.lepikhov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 31C1860810; Mon, 1 Sep 2025 12:24:01 +0300 (MSK) Message-ID: <4901f7de-c883-4af3-a3f0-345ba0e27edf@gmail.com> Date: Mon, 1 Sep 2025 11:23:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Correction of RowMark Removal During Sel-Join Elimination To: Richard Guo , Alexander Korotkov Cc: Tom Lane , Greg Sabino Mullane , PostgreSQL Hackers , Alexander Lakhin References: <18c6bd6c-6d2a-419a-b0da-dfedef34b585@gmail.com> <9b10b847-067e-45cf-bbf7-7802b6303fc0@gmail.com> Content-Language: en-US From: Andrei Lepikhov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2025/09/01 08:09:00 #27717316 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 31/8/2025 03:03, Richard Guo wrote: > On Sun, Aug 31, 2025 at 9:50=E2=80=AFAM Alexander Korotkov wrote: >> On Sun, Aug 31, 2025 at 2:51=E2=80=AFAM Richard Guo 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 g= o >>> ahead and push 0001 from my patch set shortly. >=20 >> I see. You're much farther than I'm. Please, go ahead pushing this. >=20 > Done. Hmm, is this enough? As I see, it is a typical pattern: after=20 deserialisation by the stringToNode function, Postgres attempts to call=20 eval_const_expressions. See, for example, RelationGetIndexExpressions. That seems strange, because who knows what the entry No.1 is and how=20 constant evaluation over this relation influences the expression tree.=20 Perhaps it would be beneficial to refactor all this logic? Maybe go=20 further and, before storing any relation constraint to the system=20 catalogue, replace varno with something like 'UNDEF_VAR (-5)'? I thought about why it was designed that way. Commit eabc714 shows that=20 at that time, the eval_const_expressions didn't touch PlannerInfo data=20 at all. Currently, it requires query structures in some cases,=20 particularly in prosupport functions, which necessitates having correct=20 relation references. --=20 regards, Andrei Lepikhov