public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tatsuo Ishii <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: Row pattern recognition
Date: Mon, 06 Jul 2026 15:02:21 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAAAe_zAZCeXAP73q01zdXXc2tTG7=iNM1tX4XgtbTWb02ef1-Q@mail.gmail.com>
References: <CAAAe_zBMvzn6ZwmTPhsi0mP6FPVv3hZ2cb1Xe3KD8brT5EPTFg@mail.gmail.com>
	<[email protected]>
	<CAAAe_zAZCeXAP73q01zdXXc2tTG7=iNM1tX4XgtbTWb02ef1-Q@mail.gmail.com>

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

view thread (181+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Row pattern recognition
  In-Reply-To: <[email protected]>

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

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