这两周的 PostgreSQL 社区活动横跨会议筹备、地区 Meetup、播客和社区文章。Postgres Summit US 2026 与 PGConf.PL 的议题安排取得进展，旧金山湾区和爱丁堡的本地社群继续组织技术分享，Talking Postgres 则把讨论延伸到 AI 如何改变软件开发。
两场会议进入议程落地阶段
8 月 6 日，Postgres Summit US 2026 议程委员会召开会议并最终确定日程。参与这项工作的委员会成员包括 Chelsea Dole、Jonathan Hinds 和 Jonathan Katz。
8 月 12 日，PGConf.PL 的议程委员会完成演讲筛选。委员会成员包括担任无投票权主席的 Andreas Scherbaum，以及 Adam Wołk、Hubert “depesz” Lubaczewski 和 Svitlana Lytvynenko。
对参会者来说，议程确定意味着可以开始评估具体主题、安排出行并规划学习路线。对准备投稿的开发者来说，这些活动也提醒我们：一份技术提案不能只写“介绍某个功能”，还需要明确问题、方法和听众能够带走的结论。
可以用下面这份简化模板整理未来的 PostgreSQL 会议提案。它不是相关会议的官方格式，而是一种可直接改造的写作框架：
title: "用 EXPLAIN ANALYZE 定位 PostgreSQL 查询性能问题"
audience: "熟悉 SQL、开始负责生产数据库性能的开发者"
problem: "查询变慢时，团队只能依赖猜测和反复修改索引"
what_attendees_will_learn:
- "区分估算成本与实际执行时间"
- "识别行数估算偏差、顺序扫描和低效连接"
- "在不泄露敏感数据的前提下采集执行计划"
format: "30 分钟演讲 + 10 分钟问答"
level: "intermediate"
提交前应把宽泛的主题压缩成可验证的问题，并说明示例使用的 PostgreSQL 版本、数据规模与环境限制。这样既方便评审判断内容，也能避免演讲标题承诺过多。
Meetup 让本地经验进入公共讨论
8 月 11 日，由 Katharine Saar、Stacey Haysler 和 Christophe Pettus 组织的旧金山湾区 PostgreSQL Meetup 举行活动，Kalyani Madipadiga 与 Stacey Haysler进行了分享。
8 月 13 日，PostgreSQL Edinburgh Meetup Group 在 Jimmy Angelakos 的组织下举行聚会，Torsten Förtsch 和 Paolo Guagliardo担任演讲者。
摘要没有提供这些演讲的具体主题，因此不宜进一步推断内容。不过，两场活动体现了 PostgreSQL 社区持续运转的一条重要路径：大型会议负责集中展示成熟议题，本地 Meetup 则提供频率更高、交流距离更短的反馈场景。开发者可以在本地活动中验证案例，再把内容扩展为会议提案、博客或可复现的演示项目。
从社区文章到可复现的 EXPLAIN ANALYZE 实验
本期社区文章还提到 Mayuresh Bagayatkar 对 PGConf.EU CFP 的“EXPLAIN ANALYZE”。摘要没有展开文章结论，但这个标题借用了 PostgreSQL 最常用的执行计划分析工具。借此可以做一个小型实验，理解 EXPLAIN ANALYZE 到底提供了什么信息。
下面的命令会启动一个临时 PostgreSQL 16 容器、生成十万条订单数据并分析查询计划。运行前需要安装 Docker；脚本会删除同名旧容器：
docker rm -f pg-explain-demo 2>/dev/null || true
docker run --name pg-explain-demo \
-e POSTGRES_PASSWORD=postgres \
-d -p 5432:5432 postgres:16
until docker exec pg-explain-demo pg_isready -U postgres >/dev/null 2>&1; do
sleep 1
done
docker exec -i pg-explain-demo psql -U postgres <<'SQL'
CREATE TABLE orders (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id integer NOT NULL,
status text NOT NULL,
created_at timestamptz NOT NULL DEFAULT now()
);
INSERT INTO orders (customer_id, status, created_at)
SELECT
(random() * 9999)::integer,
CASE WHEN random() < 0.08 THEN 'pending' ELSE 'completed' END,
now() - random() * interval '365 days'
FROM generate_series(1, 100000);
ANALYZE orders;
EXPLAIN (ANALYZE, BUFFERS)
SELECT customer_id, count(*)
FROM orders
WHERE status = 'pending'
GROUP BY customer_id;
SQL
输出中的 cost 是规划器估算，actual time 和 actual rows 来自真实执行，Buffers 则反映共享缓冲区命中和读取情况。由于 ANALYZE 会实际运行语句，不应直接对生产环境中的高成本查询或修改语句执行。分析 UPDATE、DELETE 等操作时，可以放进事务并在检查后回滚：
BEGIN;
EXPLAIN (ANALYZE, BUFFERS)
UPDATE orders
SET status = 'completed'
WHERE status = 'pending';
ROLLBACK;
即使使用事务，触发器、锁竞争、序列变化以及外部副作用仍需单独评估。生产排障更稳妥的做法通常是先执行不带 ANALYZE 的 EXPLAIN，再在可控环境中复现。
AI 正在进入 PostgreSQL 社区的开发话题
8 月 14 日，Claire Giordano 和 Aaron Wislang 主持并发布了 Talking Postgres 系列的新一期节目，主题是“How AI is changing software development with Simon Willison”。摘要只给出了节目主题，因此不能据此断言嘉宾给出了哪些具体结论，但选题本身说明 AI 辅助开发已成为数据库社区关心的软件工程问题。
把 AI 用于 PostgreSQL 工作流时，边界比生成普通业务代码更重要。执行计划、模式定义和错误日志可能包含表名、客户标识或业务规则。在把这些信息提交给外部模型之前，应完成脱敏，并要求模型解释依据，而不是直接接受索引或参数调整建议。
一个适合执行计划审查的提示词可以这样写：
你是一名 PostgreSQL 性能审查助手。
请分析下面的 EXPLAIN (ANALYZE, BUFFERS) 输出：
1. 区分事实、推测和仍需收集的数据。
2. 标出估算行数与实际行数差异最大的节点。
3. 最多提出三个改进实验，不要直接断言必须创建索引。
4. 为每个实验给出验证 SQL 和回滚方式。
5. 不要虚构表结构、数据分布或 PostgreSQL 配置。
执行计划：
<粘贴已经脱敏的执行计划>
采用建议：把社区输入转成工程产出
这两周的动态覆盖了内容筛选、现场交流、社区写作和新工具讨论。开发团队不必参加所有活动，但可以建立一个轻量闭环：从议程和 Meetup 中选择与当前问题相关的主题，在隔离环境复现实验，再把结果整理成内部文档或下一次投稿。
实际采用时可检查以下事项：
- 会议提案是否明确了问题、目标听众和可验证结论。
EXPLAIN ANALYZE是否在可控环境运行，并考虑语句副作用。- 分享执行计划和日志前是否删除敏感标识与业务数据。
- AI 给出的数据库建议是否经过基准测试、人工审查和回滚演练。
- 本地 Meetup 中得到的经验是否记录了 PostgreSQL 版本、数据规模和配置条件。
社区活动的价值不只在于获知新主题。真正能进入生产系统的知识，仍然需要可复现的实验、明确的适用边界和审慎的验证过程。