page145
128
Then check the effect on storage by repeating the earlier query; you may experience
latency:
SELECT active_GB,
time_travel_GB,
failsafe_GB,
retained_for_clone_GB
FROM v_table_storage_metrics
WHERE path_to_object = 'TPC.TPC_OWNER.LINEITEM_BASELINE';
Figure 4-9 shows four rows.
•
The first row is the original expected data set size.
•
The second row is after the
UPDATE
statement.
•
The third row is after the
INSERT
statement.
•
The fourth row shows the effect of the
DELETE
statement; note
that
time_travel_GB
increase due to the storage retained for the
DELETED
rows.
Figure 4-9.
DELETE storage consumption
You know micro-partitions will have been replaced due to the
DELETE
; the new data
volume is reflected in the
active_GB
column for the fourth record. As you are deleting
records, Time Travel storage is retained; this is expected behavior.
You can expect the number of micro-partitions to be about 9,405.
SELECT parse_json(system$clustering_information ( 'lineitem_baseline',
'(l_shipdate)' )):total_partition_count;
The returned micro-partition count is 9,362 indicating 4,712 micro-partitions were
removed in line with your expectations.
ChaPTer 4
MiCro-ParTiTionS