小编Jul*_*ien的帖子
SELECT FOR UPDATE 锁定 PostgreSQL 中的其他表
PostgreSQL 9.6 的情况：
- 带有整数主键的表 A
- 表 B 的主键上有外键约束，引用表 A 的主键
SELECT id FROM A FOR UPDATE;阻塞UPDATE B SET x=y;直到 A 上的锁被释放。
我认为这是因为引用的值可能会改变。我怎样才能在不删除外键约束的情况下避免第一个语句阻塞第二个语句的执行？
如果我放弃外键约束，我应该期待什么坏事？在出现这个问题的实际数据库中，如果表 B 从 A 删除后还有剩余行，这不会是一个重大问题。我们也从不更新主键。
用代码编辑：
-- Setup
create table a (id int primary key);
create table b (id int primary key references a (id) on update cascade on delete cascade, x varchar);
insert into a values (1), (2);
insert into b values (1, null), (2, null);
-- Left
begin;
select 1 from …推荐指数
解决办法
查看次数
小表会导致性能极度下降，已通过强制 VACUUM 修复。为什么？
我使用 PostgreSQL 9.6。
我有一个连接 17 个表的查询，其中 9 个有几百万行。查询运行良好，但本周其性能迅速下降。EXPLAIN 的输出没有帮助（所有扫描都是索引扫描，除了非常小的表），我不得不尝试从查询中删除表以隔离导致降级的表。
事实证明，一个包含 40 行的不起眼的表破坏了查询：800 ms 没有该表，而有 30 s。我在桌子上运行了 VACUUM FULL，它运行了大约一秒钟，现在性能恢复正常。
我的问题：
- 什么可以解释 <10kb 的表像这样破坏性能？
- 以后如何避免同样的问题？
在调试过程中，我对另一台服务器进行了基本备份，因此我有两个文件系统级别的数据库副本，其中一个我没有运行 VACUUM FULL。当我使用 pgAdmin 登录到 unvacuumed 副本时，我收到以下消息：
表“public.clients”上的估计行数与实际行数显着不同。您应该在此表上运行 VACUUM ANALYZE。
unvacuumed 表有 40 行计数和 0 估计。以下是屏幕截图中的其余统计数据。
postgresql performance statistics autovacuum postgresql-9.6 query-performance
推荐指数
解决办法
查看次数