From: Tom Lane <tgl@sss.pgh.pa.us>
To: 798604270@qq.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19358: Short circuit optimization exists in generic plan but
 missed in custom plan
In-reply-to: <19358-013f22cf91350df1@postgresql.org>
References: <19358-013f22cf91350df1@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 17 Dec 2025 12:03:44 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2727001.1766007444.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Dec 2025 16:37:24 -0500
Message-ID: <2727002.1766007444@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2727002.1766007444%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> ... So why the short
> circuit optimization applied in the prepared update (with a generic plan=
)
> but not in the normal update (with a custom plan).

Const-folding doesn't stop just because the current part of the
expression tree might not be reached at runtime.  EXPLAIN shows
that your generic plan is

regression=3D# explain verbose EXECUTE prepare_query('', '[-993693027,1525=
305818]'::int4range,
'[-168306621,-163656947)'::int4range);
                                             QUERY PLAN                   =
                           =

--------------------------------------------------------------------------=
---------------------------
 Update on public.t3  (cost=3D0.00..47.40 rows=3D0 width=3D0)
   ->  Seq Scan on public.t3  (cost=3D0.00..47.40 rows=3D157 width=3D38)
         Output: $1, ctid
         Filter: ((t3.c0 =3D t3.c0) OR ((t3.c0 >=3D (t3.c0 || (($2 - $3)):=
:text)) AND (t3.c0 <=3D t3.c0)))
(4 rows)

So the "t3.c0 =3D t3.c0" condition will be found to be true and we don't
reach the right-hand side of the OR.  However, if $2 and $3 are
replaced by constants, the planner will attempt to reduce the range
difference to a constant at plan time.

There have been previous discussions about how this sometimes leads to
unintuitive failures, but I don't see how we could skip const-folding
without huge performance penalties in some cases.  In any case, we
clearly document that you can't rely on specific execution order of
boolean expressions.  You will not find anything in our docs promising
left-to-right evaluation of ORs.

			regards, tom lane