MIME-Version: 1.0
References: 
 <CAAAe_zB4TMHnpaOrwYp7dKs553q2474ZXRytGfYOfYp4DdrgiQ@mail.gmail.com>
 <CACJufxFAQhbOD9EVCTAy-VwDbG4446N10GsxCcgdpFnjHO1Efw@mail.gmail.com>
 <CAAAe_zCQaV_im5WNbU1D1HAQDUk3yYK3nSduZZ8Qu_aK-aRA9A@mail.gmail.com>
 <20260617.221327.809417533229490738.ishii@postgresql.org>
In-Reply-To: <20260617.221327.809417533229490738.ishii@postgresql.org>
Reply-To: assam258@gmail.com
From: Henson Choi <assam258@gmail.com>
Date: Thu, 18 Jun 2026 19:43:51 +0900
Message-ID: 
 <CAAAe_zCMZKTPq74Uhq-JSdNE9kAbhtA3NSXPOcwr0W31KFeVdw@mail.gmail.com>
Subject: Re: Row pattern recognition
To: Tatsuo Ishii <ishii@postgresql.org>, jian.universality@gmail.com
Cc: zsolt.parragi@percona.com, sjjang112233@gmail.com,
 vik@postgresfriends.org,
	er@xs4all.nl, jacob.champion@enterprisedb.com, david.g.johnston@gmail.com,
	peter@eisentraut.org, li.evan.chao@gmail.com, pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="000000000000e51b9d065484da28"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAAe_zCMZKTPq74Uhq-JSdNE9kAbhtA3NSXPOcwr0W31KFeVdw%40mail.gmail.com>
Precedence: bulk

--000000000000e51b9d065484da28
Content-Type: text/plain; charset="UTF-8"

Hi Tatsuo,

Thanks -- I'll go in this direction; your sketch has the shape of it.

> Yes, I think the direction is correct. Probably the patch would someting
> like this?
>
> + update_reduced_frame(winstate->nav_winobj,
> + winstate->frameheadpos);

Right: drive the match once per row, up front, instead of letting frame
access drive it.  That's the plan, with two refinements on top of the
sketch.

First, a small refactor: I'll pull the reduced-frame loop and the mark
advance out into their own functions, called once per row before the window
functions run -- so the match tracks the row scan rather than frame reads.

Second, the mark: I'll advance it per NFA row from the match frontier rather
than the output row, so the tuplestore is trimmed as soon as the match is
done with each row.

Thanks,
Henson

--000000000000e51b9d065484da28
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Tatsuo,<br><br>Thanks -- I&#39;ll go in this direction;=
 your sketch has the shape of it.<br><br>&gt; Yes, I think the direction is=
 correct. Probably the patch would someting<br>&gt; like this?<br>&gt;<br>&=
gt; +				update_reduced_frame(winstate-&gt;nav_winobj,<br>&gt; +					 winst=
ate-&gt;frameheadpos);<br><br>Right: drive the match once per row, up front=
, instead of letting frame<br>access drive it.=C2=A0 That&#39;s the plan, w=
ith two refinements on top of the sketch.<br><br>First, a small refactor: I=
&#39;ll pull the reduced-frame loop and the mark<br>advance out into their =
own functions, called once per row before the window<br>functions run -- so=
 the match tracks the row scan rather than frame reads.<br><br>Second, the =
mark: I&#39;ll advance it per NFA row from the match frontier rather<br>tha=
n the output row, so the tuplestore is trimmed as soon as the match is<br>d=
one with each row.<br><br>Thanks,<br>Henson<br></div>

--000000000000e51b9d065484da28--