Quantcast
Channel: Teradata Developer Exchange - Blog activity for carrie's blog
Viewing all articles
Browse latest Browse all 1058

Why collect PARTITION statistics on Non-Partitioned tables? - comment by carrie

$
0
0

Growth detection relies on both RAS comparisons and row count comparisons.  Extraploation only happens if growth in a table that the statistic belongs to (let's call that statistic p_name) is detected. 
 
Starting in 12.0.3 but before 14.0 (before summary stats were available), a table's growth is detected in this way:
 
1.  PARTITION stats on a table include a column for the RAS row count at the time the PARTITION stats are collected
2.  The RAS stored in the PARTITION histogram is compared against the row count from current RAS to see if PARTITION stats are stale.
3.  If PARTITION stats are determined to be stale, the PARTITION row counts are adjusted upwards (in memory) to account for table growth
4.  Then the adjusted PARTITION stats row counts are compared against the row count from the statistic histogram (p_name)
5.  If there is a discrepany in row counts between the p_name histogram and the PARTITION row counts, extrapolation takes place for the p_name statistic
 
Starting in 14.0 (before the UseCount option was availble), a  table's growth is detected in this way:
 
1.  The summary stats (which include the RAS at the time they were collected) for the table are accessed
2.  Summary stats RAS is compared against current RAS row count
3.  If summary stats are stale, summary stat row count numbers are adjusted upwards (in memory) based on the delta with RAS
4.  Adjusted summary stats row counts are compared against the row count from the statistic histogram (p_name)
5.  If there is a discrepany in row counts between the p_name histogram and summary rows counts, extrapolation takes place
 
Thanks, -Carrie


Viewing all articles
Browse latest Browse all 1058

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>