Changes between Version 16 and Version 17 of Performance


Ignore:
Timestamp:
Aug 7, 2013, 3:43:48 PM (11 years ago)
Author:
Dimitar Misev
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Performance

    v16 v17  
    187187rasql -q 'commit'
    188188}}}
    189 Because `update test as m set m[*:*,*:*,1000] ..` will initiate creation of a completely new cube of tiles, namely `[0:99,0:99,1000:1999]`, `[0:99,99:199,1000:1999]`, etc.
     189Because `update test as m set m[*:*,*:*,1000] ..` will initiate creation of a completely new cube of tiles, namely `[0:99,0:99,1000:1999]`, `[0:99,100:199,1000:1999]`, etc.
    190190
    191191Therefore, it is best to group updates by such tile cubes, manually ''commit'' when data in one tile cube is completely ingested, and avoid jumping from update in one cube to update in another cube (e.g. slice 1, then 1000, then 2, then 1001, etc with respect to the example above). It is best when `--cachelimit` is set to at least the size of one such cube, but more is always better.