> 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
