> The change is a simplification that came out of Jian's v48 review, and it > does not change the cost the model produces. > > It follows Jian's suggestion from 2026-06-15 [1]: > >> collectPatternVariables is not needed. >> The parser already ensures every DEFINE variable appears in PATTERN, >> so there is nothing to filter. >> Also, we don't really do anything special (like make a dummy Const) >> regarding PATTERN variables that not appearing in the DEFINE clause. > > The two loops charge exactly the same set, for the following reason: > > - The old loop walked the unique PATTERN variables (collectPatternVariables > deduplicates, returning each name once) and, for each, looked up the > matching DEFINE entry by resname and charged that DEFINE's cost. > - Every DEFINE variable is guaranteed to appear in PATTERN -- the parser > rejects a DEFINE variable that is not used in PATTERN (errmsg "DEFINE > variable \"%s\" is not used in PATTERN" in parse_rpr.c). So the DEFINE > clause is always a subset of the unique PATTERN variables, and each > DEFINE resname is unique. > - A PATTERN variable that has no DEFINE contributes nothing to the old > loop, because the inner resname lookup finds no match. > > So the old loop already charged each DEFINE expression exactly once, and > nothing else. Iterating defineClause directly, as v50-0006 does, visits > precisely that same set once each. The estimate is unchanged; only the > redundant outer walk over PATTERN and the per-variable resname lookup into > the DEFINE clause are removed.
Ok, thanks for the explanation. > This also matches the premise of the cost model we settled on back in > February: the NFA executor evaluates every DEFINE expression once per row, > so the natural unit for the per-tuple charge is the DEFINE variable. BTW, I was thinking about cases where same DEFINE variable appears twice or more in PATTERN for a same row. For example PATTERN (A|A). But in this case it would be optimized out to (A). So we don't need to worry about A appearing twice. So our cost model is correct in this case. Regards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp
