Date: Mon, 06 Jul 2026 15:02:21 +0900 (JST)
Message-Id: <20260706.150221.1117486145015185971.ishii@postgresql.org>
To: assam258@gmail.com
Cc: jian.universality@gmail.com, pgsql-hackers@postgresql.org,
 zsolt.parragi@percona.com, sjjang112233@gmail.com,
 vik@postgresfriends.org, er@xs4all.nl, jacob.champion@enterprisedb.com,
 david.g.johnston@gmail.com, peter@eisentraut.org, li.evan.chao@gmail.com
Subject: Re: Row pattern recognition
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: 
 <CAAAe_zAZCeXAP73q01zdXXc2tTG7=iNM1tX4XgtbTWb02ef1-Q@mail.gmail.com>
References: 
 <CAAAe_zBMvzn6ZwmTPhsi0mP6FPVv3hZ2cb1Xe3KD8brT5EPTFg@mail.gmail.com>
	<20260704.162841.39857602849942465.ishii@postgresql.org>
	<CAAAe_zAZCeXAP73q01zdXXc2tTG7=iNM1tX4XgtbTWb02ef1-Q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260706.150221.1117486145015185971.ishii%40postgresql.org>
Precedence: bulk

Hi Henson,

> In those cases the model is still correct, for a slightly different
> reason than the (A|A) rewrite: the executor evaluates each DEFINE
> predicate once per row, not once per PATTERN occurrence.  For each
> row it evaluates every DEFINE once and keeps the boolean results in
> a varMatched array.
> 
> When the same A appears at several positions in the pattern -- for
> example the A in each branch of (A B | A C), which are distinct
> states -- each looks up varMatched[A], so the same entry is read
> more than once; but that read reuses the already-computed value, not
> a re-evaluation.  So repetition in PATTERN never multiplies DEFINE
> evaluations, and charging once per DEFINE variable in the cost model
> matches what the executor actually does.
> 
> The related question that does run the other way is that today we
> evaluate every DEFINE for a row eagerly, not just the ones that row
> actually needs.  For example, in PATTERN (A B C D) a single match
> walks the sequence one variable per row -- each row only needs to
> test the single variable its state expects -- yet we still evaluate
> A, B, C, and D at every row.
> 
> That is the short-circuit / lazy DEFINE evaluation Jian raised on
> 2026-05-26 using that very (A B C D) example (evaluate a predicate
> only the first time a state tests it).  If we ever adopt it, the
> cost model's premise -- every DEFINE once per row -- would change
> with it, so the two are tied together.
> 
> There's also a soundness angle that argues for keeping it separate.
> DEFINE already forbids volatile functions and sequence operations
> (nextval), so the obvious non-deterministic cases are out.  The
> wrinkle lazy evaluation adds is that a predicate would then be
> evaluated zero or one times per row -- skipped whenever no state
> reaches it -- rather than always.  Whether that is safe for a
> predicate carrying some state-affecting behavior the volatility ban
> does not exclude is something I haven't worked through, so it wasn't a
> call I'd want to make lightly under the current review.
> 
> As we discussed, that one is best left as a separate series after
> the initial commit, and since it was Jian's idea I'd be glad to see
> him drive it.  For now I'd keep it out of the in-flight review so the
> commit stays small.

Agreed.

Regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp