最適化ルーチンのためにPARTITION統計の収集が必要な理由について詳しくは、<Teradata Vantage™ - SQLデータ定義言語 - 詳細トピック、B035-1184>を参照してください。
PARTITIONは予約キーワードではないので、テーブル定義の列名として使用可能ですが、そうすべきではありません。このやり方はいかなる場合にも、特にパーティション テーブルでは、絶対にやめるべきです。非PARTITION列にPartitionと名前を付けると、システムはそれを通常の列として解決するからです。結果として、Partitionという名前のユーザー定義関数を持つテーブルのシステム派生PARTITION列の統計を収集できなくなってしまいます。
テーブルが単一列式によってパーティション化されている場合、その列統計はPARTITION統計として継承されます。この特殊な場合には、単一列PARTITION統計を収集する必要はありません。
例えば、次のテーブル定義を考えます。
CREATE TABLE table_1 ( col_1 INTEGER, col_2 INTEGER) PRIMARY INDEX(col_1) PARTITION BY col_2;
col_2で個別列統計を収集する場合、この列はパーティション化列なので、これらの統計もPARTITION統計として継承されます。
NPPIテーブルでPARTITION統計を収集することも可能です。この場合、テーブルの行数に関する最新のデータ統計を迅速に収集できます。これは、NPPIテーブルの各行のパーティション数が0であるためです。
単一列PARTITION統計を収集するのにUSING SAMPLE句を指定することはできますが、この指定は無視されます。システムは自動的にサンプリング パーセンテージを100に設定し直します。詳細統計レポートのサンプリング フィールドは、この動作を説明するため常に0とレポートされます。複数列PARTITION統計の場合、USING SAMPLE句に指定された有効なサンプリング パーセンテージはすべて遵守されます。
あるテーブルに収集することのできる複数列統計の数には32セットという制限があります。単一列PARTITION統計は複数列統計と同じ範囲のインデックスID(129以上160以下)を使用するので、PARTITION統計の収集は収集できる複数列統計の数の制限を31に減らしてしまいます。
システムは複数列PARTITION統計のユーザー指定の列順序付けを無視します。 これは非PARTITION複数列統計と複数列インデックスで一貫しています。 列は内部フィールドIDに基づいて順序付けられます。 システム派生のPARTITION列のフィールドIDの値は0なので、複数列統計内で常に最初の位置になります。