大插入后未使用 PostgreSQL 索引

Question

我有一个需要处理“大量”数据的应用程序：第一步是从 CSV 文件（在所描述的情况下大约 170 万行）将数据临时加载到表中，第二步是处理更新/ 根据通过一个查询加载的数据在另一张表上插入：

UPDATE destination_table d
SET ...
FROM temp_table t
WHERE d.column = t.column;

注意：temp_table 在整个过程完成后被清空

我们遇到了一些性能问题，因为 t.column 上没有索引（postgres 进程正在使用 100% 的 CPU，查询可能会卡住几个小时甚至几天），我们添加了它并且查询是“仅”在我们的环境中运行大约 5 分钟，这是完全可以接受的。

我面临的问题是在客户端环境中（相同的 RAM / vCPU 编号），索引似乎没有被使用。在其中一个中，应用程序似乎可以工作，但我们现在在同一个文件上面临同样的问题（查询卡住了几天，一个进程使用了​​ 100% 的 CPU）。

经过一番检查，我注意到索引没有在他们的环境中扫描

在我们的 pg_stat_all_indexes 告诉我这个索引：

• idx_scan : 2060888
• idx_tup_read : 3762435
• idx_tup_fetch : 3762432

在他们的环境中：

• idx_scan : 6
• idx_tup_read : 6
• idx_tup_fetch : 6

我已经和某人谈过了，他告诉我原因可能是插入后桌子没有被吸尘。一个进程已于 23/03 在他们的环境中启动（仍在“运行”...），当我查看 temp_table 上的 last_autovacuum 时，它已在 20/02（不是 03）完成，显然只有一次因为 autovacuum_count 是“1”。他告诉我，我们应该在利用过程中“强制”真空，但由于表中的插入和更新应该是连续的，我不明白它是如何工作的。

问题：

• 每次我在我的 temp_table 中加载数据时是否必须进行真空（分析？），以便在执行以下更新时正确使用我的索引？
• 什么可以解释环境之间的索引扫描差异？

Answer 1

当我查看 temp_table 上的 last_autovacuum 时，它已在 20/02（不是 03）完成，显然只有一次，因为 autovacuum_count 为“1”。

我认为临时表从未被自动清空。这是一个实际的 TEMP 表，还是您手动从中删除行的永久表？

他告诉我，我们应该在利用过程中“强制”真空，但由于表中的插入和更新应该是连续的，我不明白它是如何工作的。

我不明白这个问题。在 INSERT 和 UPDATE 语句之间插入 VACUUM ANALYZE temp_table 语句。 （或者可能只是一个分析）。

每次我在 temp_table 中加载数据时都必须进行真空（分析？），以便在执行以下更新时正确使用我的索引？

是的，如果您希望使用正确的统计信息来计划查询，则必须执行 ANALYZE。当然，这并不能保证它会使用您想要的计划。

什么可以解释环境之间的索引扫描差异？

可能是上述情况，但在不使用索引时查看“EXPLAIN (ANALYZE, BUFFERS)”的输出肯定有助于确定它。