From 0677423d1484f81b475eac241f92a73cb7f05d4d Mon Sep 17 00:00:00 2001 From: Maik Penz Date: Mon, 17 Feb 2014 10:33:10 +0100 Subject: [PATCH] iteration risk note > instead of loading the whole result into memory at once is not the full truth. There is a certain risk of processes getting killed due to memory allocation with large iteration. This is caused by result buffering of the client not being visible to PHP and thus not from 'within' the process. It is not certain that this occurs with all database clients but seems rather likely to at this point. This is only a proposal for discussion as I am not certain how to best add the information or if to add it at all (was it obvious before?). Personally I got confused by the existing description and didn't notice the memory implication until further investigation using `top` reported the process to run at 3+GB memory while PHP reported 400M real peak usage. --- docs/en/reference/batch-processing.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/en/reference/batch-processing.rst b/docs/en/reference/batch-processing.rst index f6a1b878e52..26f16ffd367 100644 --- a/docs/en/reference/batch-processing.rst +++ b/docs/en/reference/batch-processing.rst @@ -94,6 +94,12 @@ with the batching strategy that was already used for bulk inserts: fetch-join a collection-valued association. The nature of such SQL result sets is not suitable for incremental hydration. +.. note:: + + Results may be fully buffered by the database client/ connection allocating + additional memory not visible to the PHP process. For large sets this + may easily kill the process for no apparant reason. + Bulk Deletes ------------