我有一个列表,这个列表在不断增长。根据列表的大小,我正在执行批量添加。我忘记了为do executeBatch设置限制的指定大小。
程序已经运行了几个小时。我现在不想停止、修复和重新启动。
我的问题是,是什么决定了添加批次的大小?一次性使用executeBatch()
的最大容量是多少?我可以使用多少次addBatch
而不进行executeBatch()
?
我有一个列表,这个列表在不断增长。根据列表的大小,我正在执行批量添加。我忘记了为do executeBatch设置限制的指定大小。
程序已经运行了几个小时。我现在不想停止、修复和重新启动。
我的问题是,是什么决定了添加批次的大小?一次性使用executeBatch()
的最大容量是多少?我可以使用多少次addBatch
而不进行executeBatch()
?
PgJDBC在批处理方面有一些限制:
所有请求值和所有结果都必须累积在内存中,包括大型的blob / clob结果。因此,空闲内存是批处理大小的主要限制因素。
直到PgJDBC 9.4版本(尚未发布),返回生成键的批处理始终会为每个条目执行往返,因此它们与单个语句执行没有什么区别。
即使在9.4版本中,返回生成键的批处理也只有在生成的值受大小限制时才会提供好处。请求结果中的一个单独的文本、bytea或不受限制的varchar字段将强制驱动程序对每个执行执行往返。
批量处理的好处是减少网络往返次数。因此,如果您的数据库位于应用服务器本地,则几乎没有意义。随着批处理大小的增加,总等待时间快速减少,因此通常没有必要努力使批处理尽可能大。
如果您正在批量加载数据,请认真考虑使用COPY
API,通过PgJDBC的CopyManager
(通过PgConnection
接口获得)。它允许您将类似CSV的数据流式传输到服务器,以进行快速的批量加载,并且客户端/服务器往返非常少。不幸的是,它的文档相当简略 - 在主要的PgJDBC文档中根本没有出现,只有在API文档中。
org.postgresql.core.v3.QueryExecutorImpl#execute
似乎可能不会等待往返。 - Scott Dudley