PostgreSQL 通过评估当前行的排序列的逻辑值偏移来实现 RANGE 帧。当框架边界涉及 interval 类型（例如 INTERVAL '1 hour' PRECEDING）时，执行器无法通过简单的物理行计数来确定帧成员资格，因为在该时间窗口内的行数会在数据集上动态变化。为了确保正确性，引擎将整个排序分区存储到工作表中（要么在 work_mem 中，要么溢出到磁盘），扫描所有行以识别每个当前行相对于指定范围的值，导致 O(partition size) 的内存复杂度。
只有当 ORDER BY 表达式构成分区内每行的唯一键时，您才能安全地替代 ROWS 框架。如果排序列没有重复项（或者添加了一个次要唯一列，如主键），则物理行偏移（ROWS）在语义上与逻辑值偏移（RANGE）相同。这种唯一性保证确保了帧包含确切的目标行，而不需要引擎扫描值匹配的同类项，从而允许使用固定大小的环形缓冲区进行流式执行，内存使用降低到 O(frame size)。
一个高频交易平台处理纳秒精度的市场滴答数据，需要计算前 50 毫秒的买卖差价移动平均值。初始分析查询使用 AVG(spread) OVER (PARTITION BY symbol ORDER BY nanos_ts RANGE BETWEEN INTERVAL '50 ms' PRECEDING AND CURRENT ROW)。在市场波动期间，这触发了 work_mem 耗尽，迫使 PostgreSQL 将工作表溢出到磁盘，导致查询延迟从毫秒降至十几秒，这是实时算法交易无法接受的。
工程团队首先考虑垂直扩展数据库服务器，以提供足够的 RAM 来将最大分区（高交易量符号）完全存储在内存中。虽然这能消除磁盘溢出，但成本是不可承受的；最大符号包含数亿个滴答，每个数据库连接需要数 TB 的 RAM，并且该解决方案无法水平扩展以支持数千个并发交易算法。
第二个提议建议通过使用从平均滴答密度计算的固定 ROWS 偏移来近似 50 毫秒的窗口（例如，假设 1000 行等于 50 毫秒）。这种方法将保证无论分区大小如何，内存使用都是恒定的。然而，在市场崩溃期间（每毫秒数千个滴答）与平静期（几分钟没有滴答）之间，滴答密度波动非常大，使行计数近似值可能不准确，并可能违反财务法规，要求准确的时间窗口计算以便进行审计跟踪。
选择的解决方案利用了 nanos_ts 和 tick_id 形成复合唯一键的事实。团队将查询重新制定为使用 ORDER BY nanos_ts, tick_id 并切换到 ROWS BETWEEN 1000 PRECEDING AND CURRENT ROW。由于时间戳的唯一性确保逻辑的 50 毫秒边界在正常市场条件下始终与可预测的物理行偏移对齐，因此计算保持准确，同时允许 PostgreSQL 通过有界缓冲区流式处理行。查询延迟降至亚毫秒级，内存占用稳定在 O(1)，系统能够处理数十亿行的分区而无需溢出到磁盘。
为什么默认框架子句 (RANGE UNBOUNDED PRECEDING) 在 ORDER BY 列包含重复值时会产生与 ROWS UNBOUNDED PRECEDING 不同的运行总和？
当窗口函数省略显式的框架子句时，PostgreSQL 默认采用 RANGE UNBOUNDED PRECEDING。这种模式将所有共享相同 ORDER BY 值的行视为一个单独的同类组，同时包含它们所有进入框架。因此，如果用户在同一天有三笔交易，这三行的运行总和将是相同的，显示所有三笔交易加上前几天的总和。相比之下，ROWS UNBOUNDED PRECEDING 逐步计算总和：当天的第一笔交易仅包含其自身和前几天，第二笔包含前两笔，以此类推。候选人常常忽略这种默认行为，导致报告中，日内运行总和在一天的最终总和中“停滞”，破坏时间序列分析。
在评估 RANGE 帧时，PostgreSQL 如何处理 ORDER BY 列中的 NULL 值？这可能会导致哪些行在计算中被静默省略？
在 SQL 的三值逻辑中，和 NULL 的比较会产生 UNKNOWN，而不是相等。对于 RANGE 框架，PostgreSQL 通常会从有限范围窗口中排除具有 NULL 排序值的行（例如 BETWEEN 1 PRECEDING AND 1 FOLLOWING），因为与 NULL 的算术比较失败。这些行可能形成与相邻行的框架不可见的孤立同类组。如果数据集中包含 NULL 时间戳（表示遗留或待处理的数据），使用 RANGE 的移动平均将静默丢弃这些行，而 ROWS 框架将根据物理位置包含它们，无论 NULL 值如何，这可能导致分析聚合结果失真。
当 ORDER BY 列确保唯一时，为什么对大数据集仍然更倾向于显式的 ROWS 框架，而这避免了什么内部操作？
即使唯一性确保 ROWS 和 RANGE 之间的语义相等，仅存在 RANGE 关键字就会迫使 PostgreSQL 执行者为潜在的同类组扫描做准备。这会触发 Materialize 节点，在发出行之前将整个排序分区缓冲到工作表中（消耗 O(N) 内存）。通过显式声明 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，您向计划者发出了仅需要一滑动窗口的物理行的信号。这使得使用固定大小环形缓冲区的流式 WindowAgg 节点能够避免代价高昂的物化步骤，从而将内存使用降低到 O(frame size)，这对于处理数十亿行的分区而不溢出磁盘至关重要。