Yep, exactly.
It was not an issue before but the implementation changed and there were
some places that have not yet been fully converted.
That's why you see a slow-down if both the in-transaction-state as well as
the on-disk/persisted index state have to be consulted.
Will def. be fixed in 2.1 m
ah, would you mind elaborating a bit? i am just curious.
is this because any index updates would not have been committed to the
actual index until the transaction is committed, therefore there are now
_2_ indexes that must be consulted when looking up an index? The index that
is already committed,
Yep, definitely. You'd batch your transaction to sizes like 1k elements at
a time.
Usually it's more (20k-50k) but there is an issue in 2.0 that does
makes findNodesByLabelAndProperty
slower when working in larger transactions :(
On Mon, Jan 27, 2014 at 2:27 AM, Javad Karabi wrote:
> i should
i should clarify that the arguement to firstOrNull is
findNodesByLabelAndProperty, so i am assuming that most of the time is
actually in that function, that findNodesByLabelAndProperty may be whats
taking longer as the transaction grows
On Sunday, January 26, 2014 7:10:55 PM UTC-6, Javad Karabi
