| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | assam258(at)gmail(dot)com |
| Cc: | david(dot)g(dot)johnston(at)gmail(dot)com, vik(at)postgresfriends(dot)org, jacob(dot)champion(at)enterprisedb(dot)com, er(at)xs4all(dot)nl, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Row pattern recognition |
| Date: | 2026-01-03 01:04:54 |
| Message-ID: | 20260103.100454.318582476698503495.ishii@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-01-03 01:44:59 | Re: Checking join outer relation uniqueness to prevent unnecessary memoization |
| Previous Message | Jelte Fennema-Nio | 2026-01-03 00:58:25 | Re: Parallelizing startup with many databases |