page153
136
In preparation for examining how updates to cloned tables affect storage, you pick a
random
ps_suppkey
and count how many rows will be affected.
SELECT count(1)
FROM partsupp_baseline_clone
WHERE ps_suppkey = 1305848;
You should see 80 rows returned.
You cannot know how many micro-partitions will be affected at this point, but for
reference, let’s identify the current micro-partition count for both parent and child
tables. You expect the returned counts to be identical as each object references the same
micro-partitions.
SELECT parse_json(system$clustering_information ( 'partsupp_baseline',
'(ps_suppkey)' )):total_partition_count;
SELECT parse_json(system$clustering_information ( 'partsupp_baseline_
clone', '(ps_suppkey)' )):total_partition_count;
Both return 1,679 micro-partitions.
Now update your clone table called
partsupp_baseline_clone
using your random
ps_suppkey
value.
UPDATE tpc.tpc_owner.partsupp_baseline_clone
SET ps_comment = 'Clone Test'
WHERE ps_suppkey = 1305848;
You should see 80 rows updated.
And check whether storage has been affected by the
UPDATE
; you may experience latency:
SELECT path_to_object,
active_GB,
time_travel_GB,
failsafe_GB,
retained_for_clone_GB
FROM v_table_storage_metrics
WHERE path_to_object IN
( 'TPC.TPC_OWNER.PARTSUPP_BASELINE',
'TPC.TPC_OWNER.PARTSUPP_BASELINE_CLONE' );
ChaPTer 4
MiCro-ParTiTionS