Date: Sun, 31 May 2026 10:32:58 +0900 (JST)
Message-Id: <20260531.103258.1663537611708370752.ishii@postgresql.org>
To: assam258@gmail.com
Cc: jian.universality@gmail.com, zsolt.parragi@percona.com,
 sjjang112233@gmail.com, vik@postgresfriends.org, er@xs4all.nl,
 jacob.champion@enterprisedb.com, david.g.johnston@gmail.com,
 peter@eisentraut.org, li.evan.chao@gmail.com, pgsql-hackers@postgresql.org
Subject: Re: Row pattern recognition
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: 
 <CAAAe_zDephfiDA_A3FN0hCymJRogEr=Rt3QoCTf4qMYDLk+xNA@mail.gmail.com>
References: <20260517.190023.159085681032648582.ishii@postgresql.org>
	<CACJufxH-DZePhbdJM=8nNYceQiSbbXXLTw54iLhxiynQ+4hbBA@mail.gmail.com>
	<CAAAe_zDephfiDA_A3FN0hCymJRogEr=Rt3QoCTf4qMYDLk+xNA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260531.103258.1663537611708370752.ishii%40postgresql.org>
Precedence: bulk

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