Re: Row pattern recognition - Mailing list pgsql-hackers

> 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,

Ok.

> 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

Thank you for the detailed explanation. I agreed the approach.

> 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.

Looking forward to reviewing the implementation.

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