| From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
|---|---|
| To: | assam258(at)gmail(dot)com |
| Cc: | zsolt(dot)parragi(at)percona(dot)com, vik(at)postgresfriends(dot)org, er(at)xs4all(dot)nl, jacob(dot)champion(at)enterprisedb(dot)com, david(dot)g(dot)johnston(at)gmail(dot)com, peter(at)eisentraut(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Row pattern recognition |
| Date: | 2026-03-15 09:59:36 |
| Message-ID: | 20260315.185936.1050650813705779576.ishii@postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Álvaro Herrera | 2026-03-15 11:41:22 | Re: some more include removal from headers |
| Previous Message | Álvaro Herrera | 2026-03-15 09:12:33 | Re: some more include removal from headers |