1
0
mirror of synced 2025-01-19 15:01:40 +03:00

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.
This commit is contained in:
Maik Penz 2014-02-17 10:33:10 +01:00
parent 4382304e77
commit 0677423d14

View File

@ -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
------------