Re: Row pattern recognition
Tatsuo Ishii <ishii@postgresql.org>
From: Tatsuo Ishii <ishii@postgresql.org>
To: assam258@gmail.com
Cc: david.g.johnston@gmail.com, vik@postgresfriends.org,
jacob.champion@enterprisedb.com, er@xs4all.nl, peter@eisentraut.org,
pgsql-hackers@postgresql.org
Date: 2026-01-03T01:04:54Z
Lists: pgsql-hackers
Hi Henson,
Thank you for the detailed design documentation. While learning the
document, just a quick comment and question.
> Hi hackers,
>
> I've been working on an alternative implementation approach for Row
> Pattern Recognition (RPR) that addresses some limitations in the
> current regex-based patch.
>
> Key differences from the existing approach:
>
> 1. Streaming NFA instead of regex engine
> - Process rows incrementally without accumulating encoded strings
> - Avoids O(V^N) combinatorial explosion in multi-variable scenarios
Sounds good. As you already pointed out, current approach has a memory
space problem. If Streaming NFA could solve the issue, it would be
really good.
> 2. No 26-variable limit
> - Variables identified by index, not alphabet encoding
Sounds good.
> 3. Proper Lexical Order support
> - Respects PATTERN alternative order for ONE ROW PER MATCH
Here do you have "ONE ROW PER MATCH" option of RPR in your mind? In my
understanding it's in MATCH_RECOGNIZE clause, but not in RPR in Window
clause. (ALL ROWS PER MATCH is not applicable either in RPR in
Window clause).
> 4. GREEDY/RELUCTANT quantifier support
> - Longest vs shortest match semantics
Sounds good.
> 5. Incremental MEASURES computation
> - Aggregate values computed during matching, no rescan needed
>
> The attached document describes the design in detail, including:
> - Data structures (Pattern, MatchState, MatchContext)
> - Execution flow and state transitions
> - Context absorption optimization for greedy patterns
> - AST optimization passes
>
> This is still a work in progress. I'd appreciate any feedback on
> the approach before proceeding with PostgreSQL integration.
I understand you are still in the design phase and sorry for jumping
into an implementation question. but If you have an idea, please
advice:
How do you handle '{' and '}' in the PATTERN clause in the raw parser?
I am not a parser expert but it seems it's not easy to handle '{' and
'}' in gram.y.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Adjust cross-version upgrade tests for seg_out() fix
- 3e3d7875e956 19 (unreleased) cited
-
Rationalize error comments in partition split/merge tests
- ecb2508aaf9b 19 (unreleased) cited
-
Add fast path for foreign key constraint checks
- 2da86c1ef9b5 19 (unreleased) cited
-
Fix assorted pretty-trivial memory leaks in the backend.
- e78d1d6d47dc 19 (unreleased) cited
-
Add temporal FOREIGN KEY contraints
- 89f908a6d0ac 18.0 cited
-
Add trailing commas to enum definitions
- 611806cd726f 17.0 cited
-
Remove obsolete executor cleanup code
- d060e921ea5a 17.0 cited