Re: Row pattern recognition

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: assam258(at)gmail(dot)com, zsolt(dot)parragi(at)percona(dot)com, sjjang112233(at)gmail(dot)com, vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, li(dot)evan(dot)chao(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row pattern recognition
Date: 2026-06-14 02:39:42
Message-ID: CACJufxF3WB=juHAU5DwbyeNCtiUe5VOOfNTuqOYPTGEkaKf94A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jun 13, 2026 at 8:26 PM Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>
> I have created v48 RPR (Row pattern recognition) patches based on the
> attached incremental patches against v47 patches. I have briefly
> looked through all the incremental patches. If I have missed
> something, I will follow up later. The patches are based on the
> commit 3e3d7875e95 on the master branch.
>

get_windowclause_startup_tuples
do we need some comments for WindowClause->defineClause

src/backend/executor/README.rpr
(2) Transcription to WindowClause
- Copies rpPattern, rpSkipTo, initial fields

In transformRPR, we did this:
``wc->rpPattern = windef->rpCommonSyntax->rpPattern;``
Since this is an assignment, not a copy, is "Copies rpPattern" incorrect?

ISO reference typo: most occurrences use {ISO/IEC 19075},
but rpr_integration.sql and some places reference 9075-2:2016 instead of 19075.
We may need check all occurrences to ensure consistency.

In struct ResultRelInfo, we have fields like {ri_CheckConstraintExprs,
ri_WithCheckOptionExprs}.
Similarly, I want to rename WindowAggState->defineClauseList to
defineClauseExprs

I think the comment on function contain_rpr_walker can be removed,
since transformWithClause already explains it.

Is "judgment" really the right word?

I don't fully understand the purpose of eval_nav_offset_helper now.
Also, the branch where (isnull == true) and (offset < 0) appears
unreachable; it's never hit in the regression tests.
We should add some regression tests for these scenarios.

--
jian
https://www.enterprisedb.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Srinath Reddy Sadipiralla 2026-06-14 03:56:48 Re: REPACK CONCURRENTLY fails on tables with generated columns
Previous Message Alexander Nestorov 2026-06-13 23:35:14 Re: [PATCH] btree_gist: add cross-type integer operator support for GiST