page154
137
Figure 4-14 shows the expected result. Only
active_GB
storage is allocated for active
or current micro-partitions:
Figure 4-14.
partsupp_baseline and partsupp_baseline_clone Active Storage
As you see,
active_GB
for
partsupp_baseline_clone
demonstrates new micro-
partitions have been allocated for your updated data.
You might also re-check the number of micro-partitions for both the parent and
child; this may not be either informative or conclusive. You must remember it is not
possible to determine the internal clustering key attribute order. As you have only
updated the child table, the parent table micro-partition count will be constant. You
expect 1,679 micro-partitions to be returned by the next query:
SELECT parse_json(system$clustering_information ( 'partsupp_baseline',
'(ps_suppkey)' )):total_partition_count;
And for
partsupp_baseline_clone
, you might see the same number of micro-
partitions, more, or fewer depending upon whether clustering is affected by the
UPDATE
. In my environment, the next SQL statement returned the same 1,697 micro-
partition count as before:
SELECT parse_json(system$clustering_information ( 'partsupp_baseline_
clone', '(ps_suppkey)' )):total_partition_count;
Our next objective is to illustrate how storage is retained for cloned objects when the
parent is dropped. First, confirm
retention_time
is set to one day.
SELECT table_name,
retention_time
FROM tpc.information_schema.tables
WHERE table_name LIKE '%LINEITEM_BASELINE%';
You expect both
partsupp_baseline
and
partsupp_baseline_clone
are set to one
day; if not, issue the next SQL statement.
ALTER TABLE tpc.tpc_owner.partsupp_baseline
SET data_retention_time_in_days = 1;
ChaPTer 4
MiCro-ParTiTionS