 tamakyi
|
c9ebb3aebd
|
修性能回归：把「已并入 / 子段」判据做成派生列（visits.is_merged）
昨天给「已并入 / 子段」做的收口写成每行去 entity_raw 判
`raw->>'ZMERGEDTO' IS NOT NULL OR raw->>'ZPARENT' IS NOT NULL`，而 entity_raw.raw 是
**TOAST 过的整行 Core Data JSON**：一次探针要取回并解析整行。地点库「每个地点 × 5 个子查询」
的量级下 —— 实测 /places 70.1 秒、首页 43.6 秒才出页面（而库里没有任何一条 SQL 超过 1 秒：
时间全花在成千上万次「取整行再解析」上，进程 CPU 只用了 3s/135s）。
这批「渲染若干页面」的布局用例因此从 20 秒涨到 226~309 秒，整套验收从 6 分钟变 20+ 分钟。
- schema.sql：加派生列 visits.is_merged + 回填 + 给回填用的部分索引
（只索引确实带合并标记的那几十行，不用取回 raw）。
- stats.SoloVisitSQL 改成读这一列（判据仍然只此一份，读侧全部经由它）。
- 写入侧跟着刷：ingest 在 insertEntityRaw 之后、backup_merge 的 recountPlaces 里，
共用 stats.RefreshMergedFlagsSQL。
- 直接改留档里的合并标记（工具脚本 / 用例）之后也要刷一次，schema.sql 与函数注释都写明了。
实测：/places 70084ms → 206ms，/ 43633ms → 698ms（比「关掉判据」的对照还快）。
新增 page_render_budget_test.go：给 7 个关键页卡 10 秒上限的灾难探测器
（功能全对、只是慢的那种退化，之前没有任何用例会红）。
|
2026-09-30 16:18:52 +08:00 |
|
|
tamakyi
|
881f2933ff
|
收尾：验收脚本自动清死元组、城市圈首末到访按可见到访算、补使用说明
verify.sh：测试库 ≥ VACUUM_MIN_MB（默认 200MB）时先 VACUUM (ANALYZE)——一轮全量会留几百 MB
死元组，级联删除随之变慢（同一夹具用例实测 13.6s → 10.2s）。只用普通 VACUUM：FULL 要
ACCESS EXCLUSIVE 锁，有别的服务连着测试库时会把验收整段卡住。
/api/cities 的首末到访改成按可见到访的到达时间算（内层 min/max(v.arrival)），不再取
places.first/last_visit_at——那两列是全量的，会被已并入 / 子段的到访推早推晚。
README 补两节：「数据编辑页上的重复到访」（判定口径与清理范围）、「为什么有些到访在页面上看不到」
（已并入 / 子段不计入显示与统计，但导出必须原样带着），并在开发提示里记下验收环境的死元组与
is_active 两个坑。
回归：city_agg_test.go 补了一段能区分的断言——把某地点最晚那次到访标成已并入后，城市最近到访
必须从 09-13 退到 09-08（原先只比对同口径时，两种算法在夹具数据上结果一样，是条假绿的断言）。
|
2026-09-29 23:49:39 +08:00 |
|
|
tamakyi
|
3d03aae018
|
修地图城市圈的聚合口径：先按地点汇总，再按城市汇总
/api/cities 原来把聚合打在 places ⋈ visits 上：一个地点有 N 条到访，它的 visit_count 与
dwell_minutes 就被累加 N 次，count(*) 数出来的到访条数又被当成「地点数」显示——实测最大的
那个城市气泡写着「到访 72661 次 · 568 个地点」，真值是 568 次 / 86 个地点（差 128 倍）。
改成内层按地点 GROUP BY、外层按城市 sum/count，并补上「已并入 / 子段不算数」的判据，
圈的位置、排序与返回列序都不变。
回归 city_agg_test.go：手写同口径 SQL 对账 + 「地点数不可能多于到访数」的不变量；
变异验证（sum(pa.visits) *2）立刻红。
|
2026-09-29 22:07:23 +08:00 |
|