public inbox for [email protected]
help / color / mirror / Atom feedFrom: 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: Sun, 31 May 2026 10:32:58 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAAAe_zDephfiDA_A3FN0hCymJRogEr=Rt3QoCTf4qMYDLk+xNA@mail.gmail.com>
References: <[email protected]>
<CACJufxH-DZePhbdJM=8nNYceQiSbbXXLTw54iLhxiynQ+4hbBA@mail.gmail.com>
<CAAAe_zDephfiDA_A3FN0hCymJRogEr=Rt3QoCTf4qMYDLk+xNA@mail.gmail.com>
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
view thread (109+ 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