Database Postgres声称硬盘空间不足，可用空间充足

我对博士后比较陌生，但我遇到了一个奇怪的错误，谷歌搜索没有发现任何东西

我创建了两个（相对较大的）表，每个表大约有2亿行。第一个有4行，第二个有3行。他们每个人都在每个列中存储varchar

我试图创建第三个表，方法是连接两个表并选择其中三个结果列。查询是：

create table table_C as 
(select table_A.id as id, table_A.predicate, table_B.object as type 
from table_A join table_B on 
table_A.subject = table_B.subject);

查询运行约10小时，然后中止

ERROR:  could not extend file "base/446695/504075.302": No space left on device
HINT:  Check free disk space.

我在一个有64GB内存的AmazonEC2实例上运行它，我的数据库存储在一个有500GB空闲空间的卷上。我意识到生成的表应该很大，但原来的两个表只占用不到100GB的空间，因此如果一个包含两列的表占用的空间超过5倍，那就很奇怪了。我尝试了大约4次，并尝试重新启动该实例

我仔细检查了数据目录和pg_stats_tmp文件是否指向正确的卷。（postgres.conf中的“data_dir”和“pg_stat_tmp”设置）

---

有什么想法吗？是否有其他临时文件可能在某个地方膨胀（根卷的可用空间超过150GB）？

如果主题重复，连接将重复行组合

例如

表1

主题1

主题1

主题1

主题2

表2

主题1

主题1

主题2

主题2

结果将是6小时（主题1）和2行（主题2）（共8行）

在最极端的情况下-受试者完全相同-您将得到2亿*2亿行

---

我想这就是原因…

尝试使用SELECT COUNT（*）进行相同的查询，忽略所有其他选定字段。也许你有一个不需要的笛卡尔积。我试着运行count查询…它运行了大约两天，然后使Postgres服务器崩溃=\n你的意思是：

SELECT count（*）from table_A join table_B on table_A.subject=table_B.subject？A和B的定义是什么？主题列有多独特？是的，就是这个查询。表A是一组RDF数据，分为sub、pred和obj。表B有两列，第一列是主题列表，第二列是URI类型列表。表A是高度冗余的，但B至少应该接近唯一。我对SQL非常陌生，所以我可能在做一些愚蠢的事情。第一个表中的主题不是唯一的，但在第二个表中是唯一的。我试图实现的是通过使用连接在第二个表（“映射”）中“查找”键（第一个表中的主题）并返回“值”，从而在第一个表中“附加”一列，然后返回一个新行，类似于
first_table.subject second_table.value
。所以，如果我理解这是如何工作的，我不会得到一个膨胀的笛卡尔积，因为第二张表中几乎没有重复，你是对的。如果第二个表格中没有重复，您将得到与第一个表格相同的行数（可能减去第二个表格中缺少主题的一些行）