MIME-Version: 1.0
References: 
 <CAAAe_zC001P9_rpKwAiq=+hOvTV_orBchbzipZnRRzdU-UWg1A@mail.gmail.com>
 <20260314.164003.2119775273148039288.ishii@postgresql.org>
 <CAAAe_zDrCxodQG+ybLnUqo7t6e8g9kU7PEZfSF_KnibUe+Dh+g@mail.gmail.com>
 <20260315.185936.1050650813705779576.ishii@postgresql.org>
In-Reply-To: <20260315.185936.1050650813705779576.ishii@postgresql.org>
Reply-To: assam258@gmail.com
From: Henson Choi <assam258@gmail.com>
Date: Mon, 16 Mar 2026 14:39:47 +0900
Message-ID: 
 <CAAAe_zAOXMg1Mxw3vZ_9=UDObHm8JaG9tR6B-VOftV_vE63OgA@mail.gmail.com>
Subject: Re: Row pattern recognition
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: zsolt.parragi@percona.com, vik@postgresfriends.org, er@xs4all.nl,
	jacob.champion@enterprisedb.com, david.g.johnston@gmail.com,
	peter@eisentraut.org, pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="00000000000048d90a064d1da66a"
Archived-At: 
 <https://www.postgresql.org/message-id/CAAAe_zAOXMg1Mxw3vZ_9%3DUDObHm8JaG9tR6B-VOftV_vE63OgA%40mail.gmail.com>
Precedence: bulk

--00000000000048d90a064d1da66a
Content-Type: text/plain; charset="UTF-8"

Hi Tatsuo,

Thank you for the careful review and excellent questions.

I was not able to find the definition for EEOP_GT. Is this a new one?
>

You're right -- EEOP_GT does not exist. I oversimplified the example.

In PostgreSQL, comparison operators like `>` are not dedicated opcodes.
They are dispatched through EEOP_FUNCEXPR variants as regular function
calls. For example, `price > PREV(price)`:

  - The parser resolves `>` to the appropriate pg_operator entry
  - The expression compiler emits an EEOP_FUNCEXPR variant
  - At runtime, op->d.func.fn_addr points to the operator function,

I am afraid ExecEvalExpr does not allow this because ExecEvalExpr does
> not accept arguments like WindowObject or WindowAggState that are
> necessary for accessing the tuplestore created for the Window
> aggregate node.


This is the key question. You are right that ExecEvalExpr's signature
does not accept WindowAggState, and I do not intend to change it.

The approach is to pass WindowAggState through the step's own payload,
the same way EEOP_WINDOW_FUNC carries WindowFuncExprState in
op->d.window_func.wfstate. Each ExprEvalStep has a union of per-opcode
payload structs. A new payload for RPR navigation would look like:

    struct
    {
        WindowAggState *winstate;   /* access to tuplestore */
        int64       offset;         /* signed offset: PREV=-1, NEXT=+1 */
    }           rpr_nav;

The expression compiler (ExecInitExprRec) populates this when it
encounters a PREV/NEXT node, storing the pointer to the enclosing
WindowAggState. At runtime, EEOP_RPR_NAV_SET retrieves it from the
payload and uses it to fetch the target row:

    /* pseudo-code for EEOP_RPR_NAV_SET */
    winstate = op->d.rpr_nav.winstate;
    /* 1. save current slot into winstate for later restore */
    winstate->saved_outertuple = econtext->ecxt_outertuple;
    /* 2. compute target position */
    target_pos = winstate->currentpos + op->d.rpr_nav.offset;
    /* 3. fetch target row from tuplestore via winstate */
    target_slot = fetch_row_from_tuplestore(winstate, target_pos);
    /* 4. swap */
    econtext->ecxt_outertuple = target_slot;

    /* pseudo-code for EEOP_RPR_NAV_RESTORE */
    winstate = op->d.rpr_nav.winstate;
    econtext->ecxt_outertuple = winstate->saved_outertuple;

The key difference from EEOP_WINDOW_FUNC: existing steps read
precomputed values, but PREV/NEXT requires fetching a *different*
row at runtime -- because the target depends on the current row
position during pattern matching, which is not known in advance.
The mechanism for passing state is the same (step payload), but
the runtime behavior is a departure from the existing pattern.

I have examined the alternatives carefully:

  - The precomputation approach (EEOP_WINDOW_FUNC style) does not apply
    here: there is no fixed set of values to precompute, because the
    target row depends on the current position during pattern matching.

  - The three-slot model (current implementation) cannot support variable
    offsets like PREV(price, 3), and requires varno rewriting that adds
    complexity elsewhere.

  - A callback-based approach (registering a fetch function in econtext)
    would still require passing WindowAggState somehow, just through a
    different indirection.

The step payload approach is the only path I have found that:

  - Leaves ExecEvalExpr's signature unchanged
  - Eliminates varno rewriting entirely
  - Supports variable offsets naturally
  - Extends to FIRST/LAST navigation later

If anyone sees a cleaner path, I would genuinely welcome the
discussion.

I plan to have an experimental implementation ready before next week.
The initial version will pass WindowAggState broadly; we can
narrow the interface to the minimum required during review.
Let's continue the discussion with actual code.

Best regards,
Henson

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi Tatsuo,<br><br>Thank =
you for the careful review and excellent questions.</div><div dir=3D"ltr"><=
br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;=
border-left-color:rgb(204,204,204);padding-left:1ex">
I was not able to find the definition for EEOP_GT. Is this a new one?<br></=
blockquote><div><br></div>You&#39;re right -- EEOP_GT does not exist. I ove=
rsimplified the example.<br><br>In PostgreSQL, comparison operators like `&=
gt;` are not dedicated opcodes.<br>They are dispatched through EEOP_FUNCEXP=
R variants as regular function<br>calls. For example, `price &gt; PREV(pric=
e)`:<br><br>=C2=A0 - The parser resolves `&gt;` to the appropriate pg_opera=
tor entry<br>=C2=A0 - The expression compiler emits an EEOP_FUNCEXPR varian=
t<br>=C2=A0 - At runtime, op-&gt;d.func.fn_addr points to the operator func=
tion,</div><div class=3D"gmail_quote"><br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:=
solid;border-left-color:rgb(204,204,204);padding-left:1ex">
I am afraid ExecEvalExpr does not allow this because ExecEvalExpr does<br>
not accept arguments like WindowObject or WindowAggState that are<br>
necessary for accessing the tuplestore created for the Window<br>
aggregate node.</blockquote><div><br></div>This is the key question. You ar=
e right that ExecEvalExpr&#39;s signature<br>does not accept WindowAggState=
, and I do not intend to change it.<br><br>The approach is to pass WindowAg=
gState through the step&#39;s own payload,<br>the same way EEOP_WINDOW_FUNC=
 carries WindowFuncExprState in<br>op-&gt;d.window_func.wfstate. Each ExprE=
valStep has a union of per-opcode<br>payload structs. A new payload for RPR=
 navigation would look like:<br><br><font face=3D"monospace">=C2=A0 =C2=A0 =
struct<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 WindowAggState *wi=
nstate; =C2=A0 /* access to tuplestore */<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 in=
t64 =C2=A0 =C2=A0 =C2=A0 offset; =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* signed offs=
et: PREV=3D-1, NEXT=3D+1 */<br>=C2=A0 =C2=A0 } =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 rpr_nav;<br></font><br>The expression compiler (ExecInitExprRec) pop=
ulates this when it<br>encounters a PREV/NEXT node, storing the pointer to =
the enclosing<br>WindowAggState. At runtime, EEOP_RPR_NAV_SET retrieves it =
from the<br>payload and uses it to fetch the target row:<br><br><font face=
=3D"monospace">=C2=A0 =C2=A0 /* pseudo-code for EEOP_RPR_NAV_SET */<br>=C2=
=A0 =C2=A0 winstate =3D op-&gt;d.rpr_nav.winstate;<br>=C2=A0 =C2=A0 /* 1. s=
ave current slot into winstate for later restore */<br>=C2=A0 =C2=A0 winsta=
te-&gt;saved_outertuple =3D econtext-&gt;ecxt_outertuple;<br>=C2=A0 =C2=A0 =
/* 2. compute target position */<br>=C2=A0 =C2=A0 target_pos =3D winstate-&=
gt;currentpos + op-&gt;d.rpr_nav.offset;<br>=C2=A0 =C2=A0 /* 3. fetch targe=
t row from tuplestore via winstate */<br>=C2=A0 =C2=A0 target_slot =3D fetc=
h_row_from_tuplestore(winstate, target_pos);<br>=C2=A0 =C2=A0 /* 4. swap */=
<br>=C2=A0 =C2=A0 econtext-&gt;ecxt_outertuple =3D target_slot;<br><br>=C2=
=A0 =C2=A0 /* pseudo-code for EEOP_RPR_NAV_RESTORE */<br>=C2=A0 =C2=A0 wins=
tate =3D op-&gt;d.rpr_nav.winstate;<br>=C2=A0 =C2=A0 econtext-&gt;ecxt_oute=
rtuple =3D winstate-&gt;saved_outertuple;</font><br><br>The key difference =
from EEOP_WINDOW_FUNC: existing steps read<br>precomputed values, but PREV/=
NEXT requires fetching a *different*<br>row at runtime -- because the targe=
t depends on the current row<br>position during pattern matching, which is =
not known in advance.<br>The mechanism for passing state is the same (step =
payload), but<br>the runtime behavior is a departure from the existing patt=
ern.<br><br>I have examined the alternatives carefully:<br><br>=C2=A0 - The=
 precomputation approach (EEOP_WINDOW_FUNC style) does not apply<br>=C2=A0 =
=C2=A0 here: there is no fixed set of values to precompute, because the<br>=
=C2=A0 =C2=A0 target row depends on the current position during pattern mat=
ching.<br><br>=C2=A0 - The three-slot model (current implementation) cannot=
 support variable<br>=C2=A0 =C2=A0 offsets like PREV(price, 3), and require=
s varno rewriting that adds<br>=C2=A0 =C2=A0 complexity elsewhere.<br><br>=
=C2=A0 - A callback-based approach (registering a fetch function in econtex=
t)<br>=C2=A0 =C2=A0 would still require passing WindowAggState somehow, jus=
t through a<br>=C2=A0 =C2=A0 different indirection.<br><br>The step payload=
 approach is the only path I have found that:<br><br>=C2=A0 - Leaves ExecEv=
alExpr&#39;s signature unchanged<br>=C2=A0 - Eliminates varno rewriting ent=
irely<br>=C2=A0 - Supports variable offsets naturally<br>=C2=A0 - Extends t=
o FIRST/LAST navigation later<br><br>If anyone sees a cleaner path, I would=
 genuinely welcome the<br>discussion.<br><br>I plan to have an experimental=
 implementation ready before next week.<br>The initial version will pass Wi=
ndowAggState broadly; we can<br>narrow the interface to the minimum require=
d during review.<br>Let&#39;s continue the discussion with actual code.<br>=
<br>Best regards,<br><div>Henson=C2=A0</div></div></div>
</div>

--00000000000048d90a064d1da66a--