测验：计划与视界

在计划中rows=1但是actual rows=60000这个被拍到了。首先要修的是什么？

• 增加工作内存，防止排序转移到磁盘上。
• 重新抓取那个条件栏的统计数据
• 在条件列中创建索引
• 将加入顺序固定为提示

在并行计划的一个节点上rows=100000 loops=2被拍到了。这个节点实际发布的行数是多少？

• 5万行。两个工人在分工处理。
• 10万行。loops是重试次数
• 不知道。在并行计划中不显示行数。
• 20万行。显示的值是1次平均值

统计数据是旧的，只添加了索引，9.7秒变成了0.2秒。该如何看待这种情况？

• 原因已经解决了。没有索引是问题所在。
• 因为预测仍然是错误的，所以同样的事故会重复发生。
• 因为索引代替了统计，所以不需要ANALYZE了。
• 只是写作成本增加了，阅读上没有任何好处。

update只换了一个栏目，表格大小增加了1.7倍。原因是什么？

• 因为因为更新后的行导致索引被全部重新编写了。
• 因为将更新对象行直接复制到WAL中
• 因为使用了新版本，留下了旧版本。
• 因为列值增加，所以被转移到了TOAST。

VACUUM回答说这是“dead but not yet removable”。下次要去哪里？

• 打开的交易列表
• 那个表的索引雕刻程度
• autovacuum的成本延迟设定值
• 磁盘可用空间和文件系统状态

抓住地平线的会议backend_xmin用这个搜索的话，有时找不到。为什么？

• 因为backend_xmin是只有超级用户才能看到的列
• 因为统计收集器是更新值，所以会落后几秒钟。
• 因为在等待中的会话中这个列会初始化
• 写入事务以自己的backend_xid为基准，玩的时候xmin是空的