Database PostgreSQL中的最大事务大小

我的应用程序中有一个实用程序，需要执行大量的插入、更新和删除操作。我正试图围绕此创建事务，以便在调用此系统并将数据提供给它之后，可以确保将其全部或全部添加到数据库中

---

这里的边界条件是什么？一个事务中可以有多少个插入、更新和删除？事务大小是可配置的吗？

我认为事务中不存在可以执行的最大工作量。数据不断添加到表文件中，最终事务要么提交，要么回滚：AIUI此结果存储在pg_clog中；如果它向后滚动，空间最终将被真空回收。因此，这并不是说正在进行的事务工作保存在内存中，并在提交时刷新。

对于我所处理的项目，我执行了2000万次插入。我尝试了一个大的交易，每百万次插入就有一个交易，结果看起来完全一样

---

PostgreSQL 8.3

我相信最大工作量受日志文件大小的限制。数据库永远不会允许自己无法回滚，因此如果您在事务期间消耗了所有日志空间，它将停止，直到您给它更多空间或回滚。这通常适用于所有数据库

---

我建议您将更新分为可管理的块，这些块最多需要几分钟的执行时间，这样您就可以知道之前是否有问题（例如通常需要1分钟的块在10分钟后仍在运行…嗯，有人删除了索引吗？

一个事务可以在其中运行大约20亿个命令（2^31，减去IIRC一点点开销。事实上，仔细想想，这可能是2^32-我认为commandcounter是无符号的）

---

当然，这些命令中的每一个都可以修改多行。

这只是部分正确。每个事务中都有一个commandcounter，用于处理事务内部的可见性。如果事务非常大（数十亿个命令），这是一个32位数字，最终会溢出.VACUUM、pg_clog等仅处理系统中的事务总数，而不处理其中一个事务中发生的事情。@MagnusHagander此32位数字仍然有效吗？此数字是否已更新为64位？@MagnusHagander如果我理解正确，v10之前的pg_clog（以及现在的pg_xact）只包含像命令计数器这样的事务元数据，而不管事务是否已提交，实际数据仍然会在pg_xlog/pg_wal中结束。这是我在快速测试中看到的。答案给我的印象是，数据只有在提交后才会移动到wal文件。这对于PostgreSQL不是真的。我们可以在运行事务期间回收日志空间。如果您正在进行归档日志记录，则显然需要归档位置中的空间，但对于本地事务日志，则不需要。（当然，您需要磁盘上数据的实际磁盘空间）.系统是本地的吗？我认为在延迟是一个因素的系统上执行此操作，性能会有所不同。您的程序的性能没有差异。但是其他用户的性能如何？