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 →
-
Adjust cross-version upgrade tests for seg_out() fix
- 3e3d7875e956 19 (unreleased) cited
-
Rationalize error comments in partition split/merge tests
- ecb2508aaf9b 19 (unreleased) cited
-
Add fast path for foreign key constraint checks
- 2da86c1ef9b5 19 (unreleased) cited
-
Fix assorted pretty-trivial memory leaks in the backend.
- e78d1d6d47dc 19 (unreleased) cited
-
Add temporal FOREIGN KEY contraints
- 89f908a6d0ac 18.0 cited
-
Add trailing commas to enum definitions
- 611806cd726f 17.0 cited
-
Remove obsolete executor cleanup code
- d060e921ea5a 17.0 cited