6 tags for statistics

This article delves into the potential excessive use of Multi-Column (MC) Statistics and a process for identifying those that are not providing benefit and should be removed. This will reduce complexity and save resources on the re-collection of these redundant statistics.

Up 4 Down 2

I gave a presentation at the Teradata Partners Conference last week on the fundamentals of collecting statistics, where I touched briefly on the rules behind confidence levels. I’m using this article to go into further depth, and offer you more examples of how these confidence levels come about. If you look at query plans much, I’m confident you’ll find something of interest in this article.

Up 13 Down 10

Should you drop all Multicolumn statistics that are over 16 bytes?  No. There’s no need to go to that extreme. But let’s take a moment to consider the pros and cons of doing so, and how the 16-byte limit actually impacts you, or not.

Our Operations and Development teams finished the TD 12 upgrades of our two production systems several weeks back.  We have been wanting TD 12 to get to the extrapolated stats available so we could stop "munging" stats.  Our experience is that but for the problems with wide systems (below), Extrapolated Stats work, customers not in the "large" category should taking advantage and dialing back the frequency of their stats collection, particularly for PPI or Index date fields.

Have you ever had what looks like a great query plan turn into life in the slow lane at run time?

Up 44 Down 40

I’ve been telling you for years to transform your short all-AMP queries into single-AMP queries, whenever you can. I’ve even given you pointers on using stored procedures, join indexes and smart application design to achieve that goal.


But when it comes to random AMP sampling, I’m asking you to ignore all that, and give some thought to converting your random AMP sampling from one to all-AMPs.

Up 42 Down 37