Re: Row pattern recognition

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

In response to

Responses

Browse pgsql-hackers by date

  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