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
