Re: Row pattern recognition

Tatsuo Ishii <ishii@postgresql.org>

From: Tatsuo Ishii <ishii@postgresql.org>
To: assam258@gmail.com
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
Date: 2026-03-15T09:59:36Z
Lists: pgsql-hackers
Hi Henson,

> Yes. I think the key insight is that ExecEvalExpr compiles expressions into
> a flat array of ExprEvalStep operations, which makes the swap/restore
> natural
> to implement without any changes to the ExecEvalExpr caller interface.
> 
> I should also say that this approach was shaped by the constraints you
> identified early on -- the three-slot model's limitations and the need
> for variable offsets. Without that clear problem framing, I would not
> have thought in this direction.

I am not an expert of this area but I have some questions.

> The idea is to introduce two new ExprEvalOp steps:
> 
>   EEOP_RPR_NAV_SET     -- save current slot, swap to target row
>   EEOP_RPR_NAV_RESTORE -- restore original slot
> 
> These two steps bracket the inner expression steps in the flat array.
> 
> For `price > PREV(price)`:
>   1. EEOP_OUTER_VAR      -- fetch price from current slot --> datum_a
>   2. EEOP_RPR_NAV_SET    -- save current slot, swap to (currentpos - 1)
>   3. EEOP_OUTER_VAR      -- fetch price from swapped slot --> datum_b
>   4. EEOP_RPR_NAV_RESTORE -- restore original slot
>   5. EEOP_GT             -- evaluate datum_a > datum_b

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

> The EEOP_RPR_NAV_SET step would:
>   1. Save the current slot for later restore
>   2. Compute the target position from currentpos and the direction offset
>   3. Fetch the corresponding TupleTableSlot from the tuplestore

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.

That is (ExecEvalExpr doe not accept arguments like WindowObject or
WindowAggState) the reason why EEOP_WINDOW_FUNC is implemented like this:

			/*
			 * Like Aggref, just return a precomputed value from the econtext.
			 */
			WindowFuncExprState *wfunc = op->d.window_func.wfstate;

			Assert(econtext->ecxt_aggvalues != NULL);

			*op->resvalue = econtext->ecxt_aggvalues[wfunc->wfuncno];
			*op->resnull = econtext->ecxt_aggnulls[wfunc->wfuncno];

so that ExecEvalExpr can access the window function's result from
op->resvalue and op->resnull.  See eval_windowfunction for more
details.

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



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Adjust cross-version upgrade tests for seg_out() fix

  2. Rationalize error comments in partition split/merge tests

  3. Add fast path for foreign key constraint checks

  4. Fix assorted pretty-trivial memory leaks in the backend.

  5. Add temporal FOREIGN KEY contraints

  6. Add trailing commas to enum definitions

  7. Remove obsolete executor cleanup code