On 7/22/23 08:14, Tatsuo Ishii wrote:
On 7/22/23 03:11, Tatsuo Ishii wrote:
Maybe. Suppose a window function executes row pattern matching using
price > PREV(price). The window function already receives
WindowStatePerFuncData. If we can pass the WindowStatePerFuncData to
PREV, we could let PREV do the real work (getting previous tuple).
I have not tried this yet, though.
I don't understand this logic. Window functions work over a window
frame.
Yes.
What we are talking about here is *defining* a window
frame.
Well, we are defining a "reduced" window frame within a (full) window
frame. A "reduced" window frame is calculated each time when a window
function is called.
Why? It should only be recalculated when the current row changes and we
need a new frame. The reduced window frame *is* the window frame for
all functions over that window.
How can a window function execute row pattern matching?
A window function is called for each row fed by an outer plan. It
fetches current, previous and next row to execute pattern matching. If
it matches, the window function moves to next row and repeat the
process, until pattern match fails.
Below is an example window function to execute pattern matching (I
will include this in the v3 patch). row_is_in_reduced_frame() is a
function to execute pattern matching. It returns the number of rows in
the reduced frame if pattern match succeeds. If succeeds, the function
returns the last row in the reduced frame instead of the last row in
the full window frame.
I strongly disagree with this. Window function do not need to know how
the frame is defined, and indeed they should not. WinGetFuncArgInFrame
should answer yes or no and the window function just works on that.
Otherwise we will get extension (and possibly even core) functions that
don't handle the frame properly.
--
Vik Fearing
