小编Sau*_*nda的帖子

我有一个表，它使用列存储预订数据starts_at，ends_at每当我查询表以查找重叠预订时，我都可以选择使用以下查询之一：

SELECT * FROM reservations
WHERE starts_at < '2014-01-03 00:00:00'
AND   ends_at   >='2014-01-01 00:00:00';

或者

SELECT * FROM reservations
WHERE tsrange(starts_at, ends_at) && ('2014-01-01 00:00:00', '2014-01-03 00:00:00')

我在starts_at和ends_at列上有常规的 B 树索引，因此第一个查询总是使用它们。但是，除非我在 tsrange 上定义功能性 GiST 索引，否则第二个查询会执行完整扫描。

create index tsrange_idx on reservations using gist(tsrange(starts_at, ends_at)); 

我的问题是，随着表的增长，哪个索引会更快？查看查询执行计划，答案可能很明显，但我不精通读取EXPLAIN ANALYZE输出。

我一直在挠头解决以下错误，但没有取得太大进展：

$ barman switch-wal --force --archive --archive-timeout 180 pg

The WAL file 0000000100000059000000FF has been closed on server 'pg'
Waiting for the WAL file 0000000100000059000000FF from server 'pg' (max: 180 seconds)
ERROR: The WAL file 0000000100000059000000FF has not been received in 180 seconds

我之前在一次性 VPS 上配置了酒保，一切正常。但是当我尝试在我们最终的 EC2 实例上复制它时，我遇到了上面提到的问题。我确保了以下内容（即使我不记得在 VPS 上这样做过）：

• 来自酒保的 SSH => pg 正在工作
• 来自 pg 的 SSH => barman 正在工作
• “pg”上的所有防火墙规则都已暂时禁用

这里可能是什么问题？

编辑：添加输出barman check pg

Server pg:
2017-12-08 05:56:31,841 [14559] barman.server ERROR: Check 'WAL archive' failed …

最近，我们注意到许多 Rails 迁移最终在生产中导致死锁/冻结我们的应用程序+数据库。初步调查显示，这可能是由于应用程序并发访问以及对读取量非常高的表进行迁移造成的。

探索复制的 PG 设置（也许是主从）是否有意义，其中所有写入和迁移都针对主服务器执行，所有大容量读取都针对从服务器执行？

当 ALTER TABLE 语句复制到从站时，PG 的行为如何？从机是否也获取相同的表锁？复制能解决我们目前面临的问题吗？