文章

发布于

PostgreSQL 19 新特性：为什么 COUNT(*) 终于比 COUNT(1) 快了？

前言

很多开发者都纠结过 COUNT(*) 和 COUNT(1) 到底哪个更快。PostgreSQL 19 给了一个明确的答案——​数据库会自动帮你选最快的那个​。

COUNT(*) vs COUNT(1)：老生常谈的问题

在 SQL 里，COUNT 是最常用的聚合函数之一。关于这两种写法的争论已经持续了很多年：

  • ​COUNT(*)​：统计所有行数
  • ​COUNT(1)​：对每一行计算常量 1，然后统计非 NULL 的数量

理论上，如果表达式永不为 NULL（比如常量 1），这两种写法的结果​完全一样​。但在 PostgreSQL 内部，它们的执行路径却大不相同。

为什么以前 COUNT(1) 反而更慢？

在 PG 19 之前，PostgreSQL 对待 COUNT(1) 是”老实巴交”的：

  1. ​表达式计算​：对每一行都要计算一次表达式值（虽然结果就是 1）
  2. ​NULL 检查​：检查计算结果是否为 NULL（虽然 1 永远不是 NULL）
  3. ​Tuple Deform（解构元组）​：如果表达式涉及列值，数据库可能需要从磁盘行格式中提取出完整的列数据。对于列很多的宽表，这个开销会非常明显

而 COUNT(*) 走的是特化路径——​什么都不算，直接数行​，天然就少了这些开销。

PG 19 的优化：让规划器替你省事儿

PostgreSQL 19 引入了一个重要的性能补丁（Commit 42473b3），标题就是：

“Have the planner replace COUNT(ANY) with COUNT(*), when possible”

简单说：​查询规划器现在会自动把冗余的 COUNT(表达式) 重写为更高效的 COUNT(*)​。

触发条件

要触发这个优化，必须同时满足：

  1. COUNT() 里的表达式​保证不会为 NULL​（比如常量 1、NOT NULL 约束的列）
  2. 不包含 ORDER BY 或 DISTINCT 子句
-- 优化前：COUNT(1) 有额外计算开销
SELECT COUNT(1) FROM orders;

-- 优化后：PG 19 自动重写为 COUNT(*)，无需表达式计算
-- 执行计划内部等价于：
SELECT COUNT(*) FROM orders;

技术内幕：SupportRequestSimplifyAggref

这个补丁引入了一个新的支持请求类型 SupportRequestSimplifyAggref，允许聚合函数的支持函数（prosupport）检查自身的调用是否可以被简化。

对于 COUNT()，PG 新增了一个专门的支持函数，负责判断：

  • 输入表达式是否非空？
  • 有没有 ORDER BY / DISTINCT？

如果条件满足，就在查询规划阶段直接把 COUNT(ANY) 替换为 COUNT(*)，从源头上消除了不必要的表达式评估和 NULL 检查。

附带收益：更干净的执行计划

这个补丁还顺带改进了 expr_is_nonnullable() 函数，让它能正确识别常量表达式的非空性。

比如以前执行计划里可能出现的这种冗余过滤：

One-Time Filter: (100 IS NOT NULL)

现在规划器知道 100 肯定不是 NULL，直接把这个无用过滤器移除了，执行计划更清爽。

总结

写法PG 19 之前PG 19 及以后
COUNT(*)最快，直接数行依然最快
COUNT(1)慢，有表达式计算和 NULL 检查开销自动优化为 COUNT(*)
COUNT(not_null_col)慢，可能触发 tuple deform自动优化为 COUNT(*)

最终结论

  • ​PG 19 之前​：请直接写 COUNT(*)，它是性能最优的写法。
  • ​PG 19 及以后​：写 COUNT(1) 也不会吃亏了，数据库会自动帮你优化。但出于习惯和对旧版本的兼容性，​COUNT(*) 依然是最佳实践​。
发布于

Kimi K3 正式发布

月之暗面今日凌晨正式推出其迄今能力最强的模型 —— Kimi K3，一个 2.8 万亿参数的开源模型，面向长程编程、知识工作和推理等前沿智能场景设计。这是全球首个开源的 3 万亿级别模型。

Kimi K3 发布公告

核心要点

  • 2.8 万亿参数，全球首个开源 3 万亿级别模型
  • KDA 混合线性注意力机制 + 注意力残差技术
  • 原生支持视觉理解，100 万 token 上下文窗口
  • MoE 稀疏度扩大：896 个专家中激活 16 个
  • 相比 K2 整体扩展效率提升约 2.5 倍
  • 从 SFT 阶段采用量化感知训练（MXFP4/MXFP8）
  • 擅长长程编程、视觉推理和端到端知识工作
Kimi K3 架构

架构创新

Kimi K3 基于 KDA 混合线性注意力机制（Kimi Delta Attention）和注意力残差（Attention Residuals）技术构建。KDA 为注意力扩展提供高效基础，AttnRes 有选择地跨深度检索表示，二者共同使模型能扩展到万亿参数以上规模。

MoE 架构

结合 Stable LatentMoE 框架，模型可在 896 个专家中高效激活 16 个。Quantile Balancing 和 Per-Head Muon 让大规模训练更自适应。

评测对比

性能表现

虽然 Kimi K3 的整体表现仍落后于最强的闭源模型 Claude Fable 5 和 GPT-5.6 Sol，但在整套评测中展现出前沿水平的能力，并稳定超过了其他所有模型。

评测数据
能力展示

可用性

  • 用户可通过 kimi.com、Kimi 手机 App、Kimi Work 桌面客户端、Kimi Code 和 Kimi API 使用
  • 当前默认思考强度为 max（极致），后续增加 low 和 high 模式
  • 完整模型权重将于 2026 年 7 月 27 日前发布
  • 已向 vLLM 社区贡献 KDA 实现

来源：开源中国（OSCHINA）

发布于

PostgreSQL Hot Standby 查询冲突处理

冲突原因（4种）

  1. 主库 VACUUM 清理了备库查询需要的多版本数据（最常见）
  2. 主库 LOCK/DDL 产生的排他锁与备库查询冲突
  3. 主库删除表空间，但备库查询需要在其上存放临时文件
  4. 主库删除数据库，而备库仍有 session 连接

处理方式（2种）

  • 等待：让备库 WAL 应用进程等查询结束再应用 WAL
  • 取消：强制取消备库正在执行的查询

关键参数

  • max_standby_archive_delay — 归档模式最大等待延迟，默认 30s，-1 表示一直等
  • max_standby_streaming_delay — 流复制模式最大等待延迟，默认 30s，-1 表示一直等
场景 建议设置
备库用于高可用 设小值，保证不延迟
备库用于大查询 设大值

减少冲突的配置

  • hot_standby_feedback = on：备库告知主库哪些多版本数据还需要，防止 AutoVacuum 清理（推荐方案）
  • vacuum_defer_cleanup_age 调大：延迟清理多版本数据（辅助方案）

注意事项

  • 即使配置了以上参数，仍可能因冲突被取消查询
  • 备库应用应检测 canceling statement due to conflict with recovery 错误并自动重试
  • 冲突可通过 pg_stat_database_conflicts 视图查询
发布于

GLM-5.2：Z.ai 发布旗舰开源模型，1M 可用上下文挑战闭源长程任务

Z.ai 发布 GLM-5.2，1M 可用上下文 + 多级思考力度控制，开源模型首次挑战闭源旗舰长程任务能力

一、GLM-5.2 是什么

GLM-5.2 是 Z.ai 面向长程任务时代的旗舰模型。核心亮点是一个真正可用的 1M token 上下文窗口——不是在评测指标上好看，而是在真实的工程场景中能稳定工作。它能在单次任务中处理项目级别的工程上下文、可靠执行长时间运行的任务、一致性遵循工程规范，并且完成从需求到多平台部署的完整开发工作流。

二、三大新特性

  • Solid 1M 上下文：1M token 的前置上下文，能稳定支撑长程工作，不只是接受更多 token，而是在混乱的代码轨迹中保持质量。
  • 多级思考力度控制：更强的编程能力，提供 High 和 Max 两个思考努力级别，让用户在性能、延迟和计算成本之间自由平衡。
  • 纯粹开源：MIT 开源许可证——技术无国界。

三、长程任务能力：开源最强，紧追闭源旗舰

GLM-5.2 在三个长程编码基准测试中表现亮眼，全部位列开源模型第一：

基准测试说明GLM-5.2 表现排名
FrontierSWE衡量 Agent 完成数小时到数十小时的开放式技术项目落后 Opus 4.8 仅 1%，领先 GPT-5.5 1%，领先 Opus 4.7 11%开源第一，整体第二
PostTrainBench给 Agent 一块 H100 GPU，评判其对小模型的后训练改进能力超越 Opus 4.7 和 GPT-5.5仅次于 Opus 4.8
SWE-Marathon超长程任务，包括构建编译器、优化内核、开发生产级服务落后 Opus 4.8 13%仅次于 Opus 系列

这三个基准的共性在于：它们测试的不是模型能接受多少 token，而是模型在数万 token 的真实工程轨迹中能否持续保持高质量输出——这正是 GLM-5.2 的 1M 上下文训练的落脚点。

四、更强编程能力：开源标杆

在标准编程基准上，GLM-5.2 大幅领先前代 GLM-5.1，并显著缩小了与闭源前沿的差距：

基准测试GLM-5.2GLM-5.1Claude Opus 4.8Gemini 3.1 Pro
Terminal-Bench 2.181.062.085.0低于 GLM-5.2
SWE-bench Pro62.158.4——

Terminal-Bench 2.1 上 81.0 的成绩距离 Claude Opus 4.8 的 85.0 仅差 4 分，而 Gemini 3.1 Pro 已被甩在身后。

GLM-5.2 benchmark table

GLM-5.2 引入的 effort level 控制是一大亮点。在同等 token 预算下，GLM-5.2 的 Agent 编程能力显著强于 GLM-5.1，能力定位大致介于 Claude Opus 4.7 和 Opus 4.8 之间。当你遇到高难度任务时，切换到 Max 力度级别可分配更多计算资源，换取更高性能。

五、总结判断

GLM-5.2 是截至目前 开源模型在长程 Agent 任务上的最强选手。它的 1M 上下文不是噱头，而是在 FrontierSWE、PostTrainBench、SWE-Marathon 三个真实工程场景中验证过的能力。在标准编程能力上，它稳坐开源第一把交椅，并首次让开源模型与闭源旗舰的差距缩小到个位数百分比。

对于 AI Agent 开发者、长程自动化场景和需要高质量代码生成的团队，GLM-5.2 是目前开源阵营中最值得关注的选择。配合 MIT 开源协议和 Ollama 一键部署，上手几乎没有门槛。

发布于

pg_basebackup 报错：no pg_hba.conf entry for replication connection

pg_basebackup 执行报错 “no pg_hba.conf entry for replication connection” 的解决方法——别忘了 replication 虚拟库也需要一条规则

一、问题现象

执行 pg_basebackup 时报错：

[postgres@pg01 tools]$ pg_basebackup -h 10.0.0.101 -U postgres -F p -P -X stream -R -D $PGDATA -l postgresbackup20260616
2026-06-16 10:17:31.017 CST [1577] FATAL:  no pg_hba.conf entry for replication connection from host "10.0.0.101", user "postgres"
pg_basebackup: error: could not connect to server: FATAL:  no pg_hba.conf entry for replication connection from host "10.0.0.101", user "postgres"

明明 pg_hba.conf 里已经配置了 all 规则，为什么还会被拒绝？

二、问题原因

pg_basebackup 走的是 replication 连接，而 replication 并不是一个真实的数据库，它是一个虚拟库。pg_hba.conf 中的 host all all ... 规则只覆盖普通数据库连接，不覆盖 replication 连接。

因此即使配置了：

host    all             all             0.0.0.0/0               trust

pg_basebackup 依然会因为找不到 replication 规则而拒绝连接。

三、解决方案

在 pg_hba.conf 中添加 replication 规则：

host    replication     all             0.0.0.0/0               trust

重启 PostgreSQL：

pg_ctl restart

再次执行 pg_basebackup：

[postgres@pg01 backup]$ pg_basebackup -h 10.0.0.101 -U postgres -F p -P -X stream -R -D $PGDATA/backup -l postgresbackup20260616
65502/65502 kB (100%), 1/1 tablespace

备份成功。

四、总结

pg_hba.conf 中至少需要两条规则才能同时支持普通连接和 pg_basebackup 备份：

host    all             all             0.0.0.0/0               trust
host    replication     all             0.0.0.0/0               trust
  • 第一条：允许 普通数据库连接（所有数据库、所有用户、任意 IP，trust 认证）
  • 第二条：允许 复制连接（特殊的 replication 虚拟库、所有用户、任意 IP，trust 认证）

两条规则缺一不可。

发布于

追忆父亲

逝去的日子里，父亲的身影或许还在某个午后的光影中，在某句熟悉的话语里，在某个你下意识想拨电话的瞬间——他已经融入了时间的深处，却从未真正离开你的记忆与生命。

现在的生活正在发生，这可能是父亲最想看到的：你带着他给予的力量、教诲、甚至是他未曾说完的期望，继续走在阳光下。每一次你做出善良的选择，每一次你勇敢面对困难，都是与他最深情的对话。

未来的未来，从某种角度来说，并不遥远。因为当你在未来成为更好的自己，当你把父亲的爱传递给下一代，当你在某个人身上看到他的影子——那个未来，就是现在；那份重逢，一直都在。

对父亲的追忆，不是要把逝去的人拉回现在，而是让他们的光，继续照亮前行的路。

发布于

小米 MiMo-V2.5 系列 vs DeepSeek V4 性价比分析

Pro 旗舰级定价完全一致，标准级小米凭多模态实现差异化优势

小米 5 月 27 日降价与 DeepSeek 5 月 22 日宣布的永久降价！！！

一、降价后完整定价对比

计费项MiMo-V2.5-ProDeepSeek V4-ProMiMo-V2.5（标准版）DeepSeek V4-Flash
输入（缓存命中）0.025 元0.025 元0.020 元0.02 元
输入（缓存未命中）3 元3 元1 元1 元
输出6 元6 元2 元2 元
上下文窗口1M1M1M1M
多模态纯文本纯文本图像/音频/视频纯文本
开源协议MITMITMITMIT

数据来源：MiMo 官方调价公告 DeepSeek 官方定价页

两个层级的定价几乎完全镜像：Pro 级别三项单价完全一致，标准/Flash 级别也完全一致。但这里有一个关键差异——MiMo-V2.5 标准版是原生全模态模型（支持图像、音频、视频理解），而 DeepSeek V4-Flash 只是轻量级纯文本模型。同样的价格，小米给了多模态能力。

二、小米独有的成本优化机制

Token Plan 计费体系升级是小米本次降价的隐性加分项，很容易被忽略：

  • 同等价格下可用 tokens 提升至原方案的 5-8 倍
  • 引入 Credits 统一计量，计费规则”所见即所得”
  • 所有有效期内的 Token Plan 用户 Credits 于 5 月 27 日 0:00 全量重置
  • 北京时间 00:00~08:00 期间，所有模型 Credits 消耗速率再打 8 折

这意味着如果你使用 Token Plan 订阅制，小米的实际单位成本还会进一步降低。DeepSeek 目前没有同等规模的订阅优惠体系。

上下文窗口不再区分定价也是重要改进。此前小米对 256K 以上的长上下文窗口收取双倍价格，现在一律同价，这对 Agent 场景（经常需要长上下文）是直接利好。

三、性能与能力对比

根据独立第三方 Artificial Analysis Intelligence Index v4.0（截至 2026 年 5 月 6 日）的数据：

评测维度MiMo-V2.5-ProDeepSeek V4-Pro优势方
AA Intelligence Index54 分（并列开源第 1）52 分（并列第 2）MiMo
GDPval-AA Agent并列开源第 1并列开源第 1持平
ClawEval（长程 Agent）63.8%59.8%MiMo
τ³-bench（跨任务协作）72.9%71.8%MiMo
SWE-bench Verified78.9%80.6%DeepSeek
SWE-bench Pro（复杂工程）57.2%55.4%MiMo
LiveCodeBench Pass@1—93.5%DeepSeek
Codeforces Rating—3206（人类第 23）DeepSeek
Terminal-Bench 2.068.4%67.9%MiMo
幻觉率（AA-Omniscience）暂无数据94%（极高）MiMo 无数据但 DS 确认高

数据来源：CSDN 技术博客 搜狐

Token 效率是 MiMo 的重要差异化优势。MiMo-V2.5-Pro 在 Agent 长程任务中比 Kimi K2.6 节省约 42% Token，在 ClawEval 评测中比 Claude Opus 4.6、Gemini 3.1 Pro 节省 40%~60%。由于 Agent 任务 token 消耗指数级增长，省 token 直接等于省真金白银——在相同定价下，MiMo 完成同等任务的实际花费更低。

四、场景化性价比结论

场景 1：Agent 自动化与长程工作流（多步工具调用、代码工程 Agent）
推荐 MiMo-V2.5-Pro。Agent 能力在第三方评测中领先，Token 效率更高意味着实际成本更低，响应速度更快。小米取消上下文窗口差异化定价后，Agent 场景的长上下文调用不再有价格惩罚。

场景 2：竞赛编程与深度数学推理
推荐 DeepSeek V4-Pro。LiveCodeBench 93.5% 和 Codeforces 3206 分是开源最强，思考时间更长但推理深度更深。不过需要注意 94% 的幻觉率在可靠性要求高的场景中是硬伤。

场景 3：多模态任务（图像理解、音视频处理、办公自动化）
推荐 MiMo-V2.5（标准版）。DeepSeek V4 全系为纯文本模型，而 MiMo-V2.5 标准版原生支持图像/音频/视频理解，输出价格仅 2 元/百万 tokens，同等价位下 DeepSeek V4-Flash 只能处理文本。

场景 4：高频轻量调用与批量处理
MiMo-V2.5 标准版与 DeepSeek V4-Flash 定价完全相同（0.02 / 1 / 2），但 MiMo-V2.5 多模态能力覆盖更广，且 Token Plan 订阅可进一步压低成本。如果纯文本且高频调用，V4-Flash 也是可靠选择。

场景 5：订阅制与大用量部署
MiMo 占优。Token Plan 体系下同等价格可用 tokens 提升 5~8 倍，加上凌晨 8 折优惠和 Credits 全量重置，大规模部署的实际单位成本显著低于按量计费的 DeepSeek。

五、总结判断

在 Pro 级别，两家定价完全相同，性价比之争完全回归到能力差异：MiMo-V2.5-Pro 综合评分更高（54 vs 52），Agent 和 Token 效率领先；DeepSeek V4-Pro 在纯编程和数学推理上更强，但幻觉率是重大隐患。

在标准级，同样是相同定价，但 MiMo-V2.5 标准版凭多模态能力实现了真正的差异化——同样的 2 元输出价格，小米给的是图像/音频/视频全模态模型，DeepSeek V4-Flash 只是轻量纯文本模型。

叠加 Token Plan 5~8 倍加量、取消上下文窗口差异化定价、凌晨 8 折等优惠机制，小米 MiMo-V2.5 系列在整体性价比上略胜一筹，尤其对于 Agent 场景、多模态需求和订阅制用户。但如果你是竞赛编程或需要极致数学推理深度的用户，DeepSeek V4-Pro 仍然是更专业的工具。