"Reading" all of the rows first implies you're bringing back the entire result to a client, which provides you serial access to the data.
I think you should re-run test #3 that measures the time it takes to call deleteRows only. I'm emphasizing this because I've worked on projects that could quickly define a range to be deleted without reading any data, and using deleteRows decreased our latency significantly On Mon, Nov 16, 2015 at 11:19 AM, z11373 <[email protected]> wrote: > I didn't do that, but I am sure can extrapolate that from Test 1. > > Test 1 is doing: > foreach k/v in scanner's iterator > create a new mutation with that row > call putDelete > > Test 3 is doing > foreach k/v in scanner's iterator > assign the row of first entry to 'first' var > assign the row to a 'last' var > After the loop is done, pass 'first' and 'last' vars to deleteRows. > > So, if I'd extrapolate the time without reading all rows, then we can > subtract result from Test 1 from result from Test 3, i.e. for Table 1 is > 196,597 - 5,702 = 190,895 (this is still way too long) > > > > > -- > View this message in context: > http://apache-accumulo.1065345.n5.nabble.com/delete-rows-test-result-tp15569p15571.html > Sent from the Developers mailing list archive at Nabble.com. >
