perf: improve performance of bulk child entity updates and avoid hitting the AQL limit of 500 nesting limit doing it
Child entity updates generate a lot of AQL because each entity can have different kinds of updates, and some of them refer to old values. This is still the case after the optimizations.
However, previously, we performed multiple child entity updates by nesting conditional expressions like this:
This generated one level of nesting per update. ArangoDB 3.11 now limits the AQL nesting to 500, which means we would be limited to a little under 500 item updates in one mutation. In addition, a few hundred updates had realy bad performance.
Now, we convert the list into a dictionary (id -> entity), so we can more efficiently look up items and construct the new list.
This optimization is only applied after a threshold of 3 (configurable) because it involves some steps, and doing a single or two updates is probably still faster with the conditionals.
perf: improve performance of bulk child entity updates and avoid hitting the AQL limit of 500 nesting limit doing it
Child entity updates generate a lot of AQL because each entity can have different kinds of updates, and some of them refer to old values. This is still the case after the optimizations.
However, previously, we performed multiple child entity updates by nesting conditional expressions like this:
This generated one level of nesting per update. ArangoDB 3.11 now limits the AQL nesting to 500, which means we would be limited to a little under 500 item updates in one mutation. In addition, a few hundred updates had realy bad performance.
Now, we convert the list into a dictionary (id -> entity), so we can more efficiently look up items and construct the new list.
This optimization is only applied after a threshold of 3 (configurable) because it involves some steps, and doing a single or two updates is probably still faster with the conditionals.