Re: Row pattern recognition

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: assam258(at)gmail(dot)com
Cc: jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row pattern recognition
Date: 2026-01-16 04:44:22
Message-ID: 20260116.134422.281440144321973927.ishii@postgresql.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Henson,

> Hi Ishii-san,
>
> Thank you for raising the frame boundary concern. You're right that
> different contexts have different frame boundaries.

Ok.

> Your suggestion was to use row_is_in_frame() to check frame boundaries
> for each row. However, I took a simpler approach: just disable context
> absorption entirely when the frame is limited.
>
> The root cause is that context absorption assumes all contexts see
> the same rows. With limited frames, each context starting at a different
> row has a different visible range, so we cannot absorb one context into
> another.
>
> As I mentioned before, I think we should use absorption conservatively
> for now - only in cases where it's clearly safe (e.g., A* at the
> beginning of the pattern). We can extend it later through more in-depth
> research.

Agreed.

> The fix:
>
> if (winstate->rpSkipTo == ST_PAST_LAST_ROW && !hasLimitedFrame)
> nfa_absorb_contexts(winstate, targetCtx, currentPos);
>
> I added a test case to verify this:
[snip]
> I'm attaching three related commits:
>
> 1. Row pattern recognition: Improve NFA state memory management
>
> This commit refactors NFA state management for better readability
> and maintainability.
>
> 2. Row pattern recognition: Disable context absorption for limited frame
>
> This commit further restricts absorption: even with SKIP PAST LAST ROW,
> absorption is disabled when the frame is limited. With limited frames,
> different contexts have different frame boundaries, making absorption
> unsafe.

I have applied the patches on top of v38 to create v39 patches.
In addition to these patches, I have made following changes:

- Add check for frame option "EXCLUDE". With RPR, using EXCLUDE is not
permitted by the SQL standard. A test case added.

- Remove unused typedef from windowfuncs.c (which causes removal of the
typedef from typedes.list). The typedef was accidentally left by me
while developing RPR.

- Update the Copyright year to 2026 in some newly added files.

Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp

Attachment Content-Type Size
v39-0001-Row-pattern-recognition-patch-for-raw-parser.patch application/octet-stream 26.4 KB
v39-0002-Row-pattern-recognition-patch-parse-analysis.patch application/octet-stream 24.3 KB
v39-0003-Row-pattern-recognition-patch-rewriter.patch application/octet-stream 5.7 KB
v39-0004-Row-pattern-recognition-patch-planner.patch application/octet-stream 40.6 KB
v39-0005-Row-pattern-recognition-patch-executor-and-comma.patch application/octet-stream 66.3 KB
v39-0006-Row-pattern-recognition-patch-docs.patch application/octet-stream 11.1 KB
v39-0007-Row-pattern-recognition-patch-tests.patch application/octet-stream 181.5 KB
v39-0008-Row-pattern-recognition-patch-typedefs.list.patch application/octet-stream 1.2 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message 洪伊 2026-01-16 04:59:56 Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t
Previous Message Tom Lane 2026-01-16 04:43:33 Re: [PATCH] pl: fix can not build free-thread for plpython extension like 3.14t