Postgresql 使用GIN索引更新大型表时，磁盘使用率会急剧上升
我们在RDS上有一个中型数据库，运行10.1（32核，240 GB RAM，5TB总磁盘空间，20k PIOPS）和几个大型（100GB+，数千万行）表，这些表使用GIN索引进行全文搜索。我们有时需要索引非常大（数百页）的文档，因此我们的表中混合了小（数十个令牌）到非常大（接近tsvector 1MB限制的几十万个令牌）。我们所有的GIN索引都关闭了fastupdate——我们发现打开fastupdate会导致显著的阻塞，并且关闭它后我们可以获得更好的平均性能。在过去几年中，我们花了大量精力调整数据库，使这些表具有可接受的读写性能 一个反复出现的，可预测的，我们多年来经常遇到的问题是，在任何具有GIN索引的表中插入或更新行都会导致可用磁盘空间大幅下降，即插入总大小为10GB的10k行可能会导致在2-3小时内临时损失数百GB的可用磁盘空间（可能更多-我们试图保留10-15%的可用磁盘空间缓冲区，以便通常代表几乎所有可用磁盘空间）。一旦停止操作，可用磁盘空间会迅速恢复，这让我们相信这是由于日志或某种临时表造成的。我们的工作记忆和维护工作记忆设置相当大（分别为12GB和62GB）。在此过程中，数据库在磁盘上的大小几乎没有变化 不幸的是，我们使用的是RDS，因此无法通过ssh直接访问实例来查看哪些文件如此之大，而且我们可以看到的日志（或wal日志）都不足以解释此过程。是否有任何关于从何处查找此问题原因的建议（或关于我们可以调整的任何设置或我们可以进行的更改以停止）将不胜感激 谢谢大家!Postgresql 使用GIN索引更新大型表时，磁盘使用率会急剧上升,postgresql,Postgresql,我们在RDS上有一个中型数据库，运行10.1（32核，240 GB RAM，5TB总磁盘空间，20k PIOPS）和几个大型（100GB+，数千万行）表，这些表使用GIN索引进行全文搜索。我们有时需要索引非常大（数百页）的文档，因此我们的表中混合了小（数十个令牌）到非常大（接近tsvector 1MB限制的几十万个令牌）。我们所有的GIN索引都关闭了fastupdate——我们发现打开fastupdate会导致显著的阻塞，并且关闭它后我们可以获得更好的平均性能。在过去几年中，我们花了大量精力调整