RANGE窗口不能合并重叠时间区间，因其仅按值域滑动采样，不识别或合并重叠段；正确做法是用tsrange+&&+range_agg()、贪心窗口（需有序）或递归CTE。
PostgreSQL 里没有 RANGE 窗口聚合能直接处理“时间重叠”——RANGE 是窗口帧（frame）定义方式，它按值域滑动（比如 ORDER BY ts RANGE BETWEEN INTERVAL '1 hour' PRECEDING AND CURRENT ROW），但不判断区间是否重叠，也不合并重叠段。真要处理重叠，得靠递归 CTE、自连接或 range 类型 + && 操作符。
为什么 RANGE 窗口不能用于合并重叠时间区间
RANGE 窗口只控制“当前行前后多少值范围内的行参与计算”，比如按时间排序后取前 1 小时内的记录做 AVG()；但它不会识别 [09:00,10:30] 和 [10:15,12:00] 是否重叠，更不会把它们自动合并成 [09:00,12:00]。这是语义错配：窗口帧是“滑动采样”，而重叠合并是“集合运算”。常见错误是写 MAX(end_time) OVER (ORDER BY start_time RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)，结果只是累积最大右端点，不是逻辑合并——若中间有空隙，也会被拉平。
用 tsrange + && + range_agg() 合并重叠段最直接
PostgreSQL 的 tsrange 类型配合专用操作符和聚合函数，才是处理重叠的正路：
- 确保字段是
tsrange类型，或用tsrange(start_ts, end_ts, '[)')构造，别存字符串 - 必须建
GIST索引：CREATE INDEX idx_events_range ON events USING gist (r)，否则&&查询全表扫 - 合并用
range_agg(r)（需启用postgres-contrib），但它不排序也不容错：输入必须有效（lower ）、非空，否则报错 <code>range lower bound must be less than upper bound - 安全写法要先清洗：
SELECT range_agg(r) FROM (SELECT tsrange(start_time, end_time, '[)') AS r FROM events WHERE start_time
用窗口函数贪心合并（仅限左端点有序场景）
当数据已按 start_time 升序排列，且允许“紧邻即合并”（如间隔 ≤5 分钟视为连续），可用窗口函数模拟贪心算法：
- 先按
start_time排序，用LAG(end_time) OVER (ORDER BY start_time)拿到上一段结束时间 - 定义新组条件：
CASE WHEN start_time - 用
SUM()窗口累计生成组号：SUM(is_new_group) OVER (ORDER BY start_time) - 最后
GROUP BY group_id，取MIN(start_time)和MAX(end_time) - ⚠️ 注意：
RANGE BETWEEN在这里没用——必须用ROWS UNBOUNDED PRECEDING确保顺序累积，否则窗口无法跨行传递状态
自连接 + 递归 CTE 是通用解法，但索引和收敛性很关键
对无序、任意重叠、需精确合并的场景，递归 CTE 最可靠，但极易写崩：
- 初始查询必须选“不被任何更早区间覆盖”的记录（用
NOT EXISTS+e2.start_time = e1.start_time），否则第一层就漏数据 - 递归部分
JOIN条件必须含重叠判断：e.start_time = m.start_time，且排除已加入的 ID（NOT e.id = ANY(m.members)） - 没索引时，自连接部分会
O(n²)扫描；必须有(start_time, end_time)复合索引，且类型匹配（别在表达式上建索引） - PostgreSQL 默认递归深度 100，重叠链过长会中止；可临时调大
SET statement_timeout = '30s'; SET search_path TO public;不起作用，得改max_recursive_depth（需 superuser）
真正难的不是语法，是区分“滑动统计”和“区间合并”——前者用 RANGE 窗口，后者必须跳出窗口思维，用 range 类型或图式合并。一旦混淆，查出来的“合并结果”看起来像那么回事，实则空隙被抹平、重叠被忽略，工时或资源占用算出来就偏了。
