| 41 | |
| 42 | === Caveat === |
| 43 | |
| 44 | Regular tiling always creates full tiles according to the tiling scheme, even when an insert or update statement affect only a single pixel. The rest of the pixels in the tile are filled with 0. For example the query below will create an object of size `[0:99,0:49]`, rather than `[0:1,0:1]`: |
| 45 | {{{ |
| 46 | insert into test |
| 47 | values |
| 48 | marray x in [0:1,0:1] values 1c |
| 49 | tiling regular [0:99,0:49] |
| 50 | index rc_index |
| 51 | }}} |
| 52 | |
| 53 | This has important consequences as number of dimensions increase. Consider this case for example: |
| 54 | {{{ |
| 55 | insert into test |
| 56 | values |
| 57 | marray x in [0:999,0:999,0:0] values 1c |
| 58 | tiling regular [0:99,0:99,0:999] |
| 59 | index rc_index |
| 60 | }}} |
| 61 | Even though it inserts just one slice of size 1000x1000, this slice will initiate creation of 100 tiles of size 100x100x1000, i.e. 1000x more data will be actually inserted. Running partial updates later on as below will require constantly reading and writing the whole cube of 1000x1000x1000, even though each partial update is one slice of 1000x1000x1: |
| 62 | {{{ |
| 63 | update test as m set m[*:*,*:*,1] assign marray x in [0:999,0:999] values 1c |
| 64 | update test as m set m[*:*,*:*,2] assign marray x in [0:999,0:999] values 1c |
| 65 | update test as m set m[*:*,*:*,3] assign marray x in [0:999,0:999] values 1c |
| 66 | ... |
| 67 | }}} |
| 68 | In such a case, using [wiki:Performance#Tilecache tile caching] is particularly important for maintaining reasonable data ingestion speed. |