Hi. ``The actual mark is set to: min(lookback_mark, lookahead_mark).`` in README.rpr need update?
The attached patch is still based on https://github.com/assam258-5892/postgres/commits/RPR. v50-0001-Refactor-visit_nav_plan.partial v50-0002-Refactor-visit_nav_exec.partial v50-0003-no-need-compile-and-evaluate-offset-in-expression-evaluation.partial v50-0004-misc.partial v50-0001-Evaluate-navigation-offset-once-at-one-place.nocfbot The ".partial" patch, when combined, contains the same content as the single patch (v50-0001-Evaluate-navigation-offset-once-at-one-place.nocfbot). (I first created separated patches, but then I felt the whole change focuses on one main topic, so merging them made sense to me). The commit message for the main patch (v50-0001-Evaluate-navigation-offset-once-at-one-place.nocfbot) is below: ------------------------------------------------ Subject: [PATCH v51 1/1] Evaluate navigation offset once at one place Row pattern navigation (PREV/NEXT/FIRST/LAST and their compounds) resolved offsets (transform a expression to a int64 number) in ExecInitExprRec, ExecEvalRPRNavSet, extract_const_offset, eval_define_offsets. Serval places transform the same offset expression to a int64 number, that is too much! With the attached, a single place (ExecInitWindowAgg->eval_define_offsets) to handling this. visit_nav_exec() now evaluates every offset expression at executor init and save the result on the RPRNavExpr (offset / compound_offset); ExecEvalRPRNavSet() simply reads those int64 values. This removes: - the RPRNavOffsetKind enum and the offset/kind fields on the WindowAgg plan node. The planner walk (visit_nav_plan / compute_define_metadata) now only classifies match_start dependency, which is all buildRPRPattern() needs to decide context absorption. - the per-invocation offset machinery in the executor: the Datum* offset arrays in the eval step, rpr_nav_get_compound_offset(), and the scattered NULL/negative checks, now centralized in eval_nav_offset. The "retain all" case (backward reach overflows int64) is encoded as the sentinel navMaxOffset < 0 rather than an enum value; advance_nav_mark() disables tuplestore trim on it. EXPLAIN reads the resolved offsets from the planstate (ExecInitWindowAgg is reached for EXPLAIN without ANALYZE), so it now prints concrete offsets instead of "runtime". ``` We must still set nav_saved_outertuple (done above) so that EEOP_RPR_NAV_RESTORE is a harmless no-op. ``` The above in ExecEvalRPRNavSet is wrong, EEOP_RPR_NAV_RESTORE will never be a no-op. However we can make EEOP_RPR_NAV_RESTORE no-op, so the above comments make sense. Rename eval_nav_offset_helper to eval_nav_offset Based on https://github.com/assam258-5892/postgres/commits/RPR ------------------------------------------------ -- jian https://www.enterprisedb.com/
v50-0001-Evaluate-navigation-offset-once-at-one-place.nocfbot
Description: Binary data
v50-0001-Refactor-visit_nav_plan.partial
Description: Binary data
v50-0004-misc.partial
Description: Binary data
v50-0003-no-need-compile-and-evaluate-offset-in-expression-evaluation.partial
Description: Binary data
v50-0002-Refactor-visit_nav_exec.partial
Description: Binary data
