Google Cloud Local SSD可以用于PostgreSQL临时表空间吗？

Question

我们在Google Cloud的VM中运行PostgreSQL实例。我们运行的查询的性质涉及许多PostgreSQL临时表空间。 （每天5或6个或更多 TB 磁盘I / O）

这个I / O仍然是我们数据库的主要瓶颈。目前我把它全部发生在SSD持久性磁盘上 - 不是因为我们需要在重启时保存任何数据，而是因为PostgreSQL在磁盘上布局了一个文件结构，然后它用于临时表，如果数据库启动时文件结构丢失，不是很好。

我想要做的是在本地SSD上配置临时表空间，因为它们的I / O吞吐量要高得多。不幸的是，它们在每次重启时都会被清除。我想要一种简单的方法，可以在重启后和PostgreSQL重启之前重新布局磁盘。

我可以对空文件结构进行tar操作，然后编写一个脚本，在每次启动后解压缩它。那有意义吗？这样做有更好的方法/最佳实践吗？

如果有一个PostgreSQL扩展可以神奇地做到这一点，那将是多么棒的。

想法？

Answer 1

我在之前的测试中挖了一些，这里有一些总结：

PostgreSQL表空间只是一个目录 - 没什么大不了的。另外 - 如果您只将它用作临时表空间，则在关闭数据库时不会有任何持久性文件。

您可以在所需的任何位置为临时表创建表空间，然后转到此位置并检查目录结构以查看PG创建的内容。但你必须在OS下做，因为PG只显示表空间主目录 - psql中的\ db +或select oid, spcname, pg_tablespace_location(oid) from pg_tablespace;的工作方式相同。

我的例子：

• （我使用/ tempspace / pgtemp作为假设的安装点）CREATE TABLESPACE p_temp OWNER xxxxxx LOCATION '/tempspace/pgtemp';在我的案例结构中创建/tempspace/pgtemp/PG_10_201707211
• 我在postgresql.conf中设置temp_tablespaces = 'pg_temp'并重新加载配置。
• 当我使用create temp table ....时，PG添加了另一个子目录 - /tempspace/pgtemp/PG_10_201707211/16393 = oid of schema - 但这与临时表空间无关，因为如果该子目录将丢失，PG将创建它。
• 在此子目录文件中为临时表创建的PG。
• 当我关闭此会话时，临时表的文件已经消失。

现在我停止了PG并测试了如果目录丢失会发生什么：

• 我删除了PG_10_201707211及其子目录
• 启动了PG，日志显示消息LOG: could not open tablespace directory "pg_tblspc/166827/PG_10_201707211": No such file or directory，但PG已启动
• 我尝试创建临时表 - 我收到错误消息ERROR: could not create directory "pg_tblspc/166827/PG_10_201707211/16393": No such file or directory SQL state: 58P01
• 现在（运行PG）我在OS中发出了这些命令：
  • sudo mkdir -p / tempspace / pgtemp / PG_10_201707211
  • sudo chown postgres：postgres -R / tempspace / pgtemp
  • sudo chmod 700 -R / tempspace / pgtemp
• 我尝试再次创建临时表并插入并选择值，一切正常

所以结论是 - 因为PG表空间不是“大魔术”只是目录，你可以简单地创建在linux启动时运行的bash脚本，它将检查（并在必要时安装）本地SSD并为PG临时表空间创建必要的目录。