Thread

Re: Row pattern recognition

Tatsuo Ishii <ishii@postgresql.org> — 2026-05-31T01:32:58Z

Hi Henson,

>> For src/backend/executor/README.rpr:
>> We should explicitly explain 'absorbable' and 'absorption' somewhere in
>> README.rpr, as the text currently just assumes the reader knows what they
> mean.
>> Using some example illustrate "absorption" meaning, put it on
>> README.rpr would be great.
>> We can also mention that 'DFS' refers to Depth-First Search".
> 
> Acknowledged, and the request surfaced an underlying problem in the
> README's terminology. "Absorption" is currently used for two
> distinct things: an AST-level rewrite in Phase 1 that pulls
> identical sequences around a group inside it, and the runtime
> context-equivalence collapse that drives the O(n^2) -> O(n)
> optimization. Sharing the word leaves a reader encountering
> "absorbable" early on without an anchor.
> 
> Rather than disambiguate by qualifier ("prefix/suffix absorption"
> vs "context absorption"), I'd lean toward renaming the AST-level
> case so "absorption" stays reserved for the runtime concept. The
> README then only needs to explain absorption in one place, in
> detail, without the disambig preamble.
> 
> For the rename, "prefix/suffix merging" feels like the natural fit
> -- the other AST-level optimizations in the same Phase 1 are already
> named "consecutive variable / group / ALT merging", so it slots in
> cleanly. "Prefix/suffix factoring" is another candidate if a more
> descriptive verb is preferred.
> 
> Tatsuo, curious what you think of this direction and naming. Happy
> to take any name you prefer for the AST-level operation, or to keep
> the original "absorption" wording with stronger forward-references
> if you'd rather not rename.

Although I don't have any particular strong preferences, keeping
"absorption" for the runtime concept sounds good to me.

For AST level name changing, "prefix/suffix merging" seems to be
already used in other areas according to Google: LLM, Linker, and
string manipulation in DNA. In the normal expression engine area, it
looks like "flattening nested quantifiers" or "quantifiers reduction"
are used for the case. So, for example, "prefix/suffix quantifiers
reduction" seems to be more appropriate?  (If you don't mind it's too
long) In any case, I would like to respect your opinion.

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