Re: delete is too slow, sometimes even causes OOM

[frank li]

I enforced  a lazy flag in DELETE code for tesing, but it is stil running very 
slow. I mean that "Lazy" flag cannot solve the problem of running too slow.

On 2020/11/06 09:50:15, Юрий  wrote: 
> Hi Frank!
> 
> There is an old ticket [1] - We will try to prioritize it to finish before
> the end of the year it should prevent OOM for most cases.
> 
> [1] https://issues.apache.org/jira/browse/IGNITE-9182
> 
> вт, 3 нояб. 2020 г. в 18:53, frank li :
> 
> > Current code logic for DELETE is as follows:
> > if WHERE clause contains a condition as "key=xxx", it uses fastUpdate
> > which remove the related item directly.
> >
> > else
> > do select for update;
> > for each row, call closure code "RMV" to remove it.
> >
> > 1. As "executeSelectForDml" get _KEY and _VAL columns for all condidate
> > rows, it often causes OOM when there are a lot of data  to delete. Why do
> > we verify "val" during remove operation?
> >
> > 2. After selection,  why don't we just remove it with cache.remove as
> > fastUpdate does?
> >
> >
> >
> 
> -- 
> Живи с улыбкой! :D
> 

delete is too slow, sometimes even causes OOM

[frank li]

Current code logic for DELETE is as follows:
if WHERE clause contains a condition as "key=xxx", it uses fastUpdate which 
remove the related item directly.

else
do select for update;
for each row, call closure code "RMV" to remove it.

1. As "executeSelectForDml" get _KEY and _VAL columns for all condidate rows, 
it often causes OOM when there are a lot of data  to delete. Why do we verify 
"val" during remove operation?

2. After selection,  why don't we just remove it with cache.remove as 
fastUpdate does?