我们在运行10.1的RDS上有一个中型数据库（32个核心，240 GB RAM，5TB总磁盘空间，20k PIOPS），其中包含几个大型（100GB +，数千万行）表，这些表使用GIN索引文字搜索。我们有时需要索引非常大（数百页）的文档，因此我们的表格混合了很小的（数十个令牌）到非常大的（几乎成千上万的令牌，接近tsvector 1MB的限制）。我们所有的GIN索引都关闭了fastupdate - 我们发现快速更新导致了严重的阻塞，并且我们在关闭时获得了更好的平均性能。在过去的几年里，我们已经花了很多精力来调整我们的数据库，以至于我们对这些表有可接受的读写性能。
我们多年经常遇到的一个反复出现且可预测的问题是，在任何带有GIN索引的表中插入或更新行会导致可用磁盘空间大幅下降 - 即插入10k行，总大小为10GB可能会导致在2-3小时内暂时丢失几百GB的可用磁盘空间（可能会更多 - 我们尝试保留10-15％的可用磁盘空间缓冲区，以便通常代表几乎所有可用的磁盘空间） 。一旦我们停止操作，可用磁盘空间迅速恢复，这使我们相信这是由于日志或某种临时表而发生的。我们的work_mem和maintenance_work_mem设置非常大（分别为12GB和62GB）。在这个过程中，数据库在磁盘上的大小几乎没有变化。
不幸的是，我们使用的是RDS，因此我们无法直接ssh到实例中查看哪些文件如此之大，而且我们看不到的任何日志（也不是wal日志）都足以解释这个处理。任何关于在哪里查看此问题原因的建议（或关于我们可以调整的任何设置或我们可以做出的更改以阻止它）都将非常感激。
谢谢！