2026년 3월 21일 (토) 23:16, Tatsuo Ishii <[email protected]>님이 작성:
> Hi Henson, > > >> So, if RPR is active, WinSetMarkPosition() is not called at all? That > >> seems too strong limitation. Can't we set mark at frameheadpos even > >> if RPR is active? It seems safe since the only allowed franme start > >> option is ROWS BETWEEN CURRENT ROW and we never step back to the rows > >> before frameheadpos. > > > > > > You raise a valid point. Setting mark at frameheadpos would be safe > > for the window function's own read pointer, since we only allow > > ROWS BETWEEN CURRENT ROW. > > > > However, the difficulty is with the PREV/NEXT navigation. In the > > experimental patch, PREV accepts an optional offset argument -- > > e.g. PREV(price, N) -- and this offset can be a runtime expression > > whose value is not known until evaluation time. If the mark is > > advanced to frameheadpos, PREV(price, N) with a large N could try > > to access rows that the tuplestore has already truncated. > > > > This is why the experimental patch takes a different approach: it > > creates a separate nav_winobj with its own mark pointer pinned at > > position 0, so that the tuplestore never truncates rows that PREV > > might need. The window function's own mark management is left > > unchanged. > > > > The mark=0 approach is safe but conservative -- it prevents the > > tuplestore from releasing any rows within the partition. The SQL > > standard (ISO/IEC 19075-5, Subclause 5.6.2) requires the offset > > argument to be a "runtime constant" -- meaning it cannot reference > > columns or row pattern variables. So in practice, the maximum > > offset is always known at plan time, which opens the door for a > > future optimization: advance the mark to (currentpos - max_offset) > > when all PREV offsets in the DEFINE clause are constant. > > > > Since the experimental patch redesigns how mark works for PREV/NEXT > > navigation, I think we should drop 0004 from the current series > > and revisit the set_mark question together with the experimental > > patch. What do you think? > > Agreed. So I just want to make sure I create v46 using 0001-0003 and > 0005-0015. Am I correct? Yes, that’s right! > Best regards, > -- > Tatsuo Ishii > SRA OSS K.K. > English: http://www.sraoss.co.jp/index_en/ > Japanese:http://www.sraoss.co.jp >
