CREATE TABLE AS - Amazon Redshift
構文パラメータ

CREATE TABLE AS

トピック

クエリに基づいて新しいテーブルを作成します。このテーブルの所有者は、このコマンドを発行したユーザーになります。

新しいテーブルが作成され、コマンドのクエリで定義されたデータがロードされます。テーブルの列には、クエリの出力列に関連付けられた名前とデータ型が指定されます。CREATE TABLE AS (CTAS) コマンドを実行すると、新しいテーブルが作成され、新しいテーブルをロードするクエリが評価されます。

構文

CREATE [ [ LOCAL ] { TEMPORARY | TEMP } ]
TABLE table_name
[ ( column_name [, ... ] ) ]
[ BACKUP { YES | NO } ]
[ table_attributes ]
AS query

where table_attributes are:
[ DISTSTYLE { AUTO | EVEN | ALL | KEY } ]
[ DISTKEY( distkey_identifier ) ]
[ [ COMPOUND | INTERLEAVED ] SORTKEY( column_name [, ...] ) ]

パラメータ

LOCAL

このオプションのキーワードは、ステートメントに指定できますが、Amazon Redshift では効果がありません。

TEMPORARY | TEMP

一時テーブルを作成します。一時テーブルは、作成したセッションの終了時に削除されます。

table_name

作成するテーブルの名前。

重要

「#」で始まるテーブル名を指定すると、そのテーブルは一時テーブルとして作成されます。例:

create table #newtable (id) as select * from oldtable;

テーブル名の最大長は 127 バイトです。それより長い名前は 127 文字まで切り詰められます。Amazon Redshift は、ノードタイプごとにクラスターあたりのテーブル数のクォータを適用します。次の表で示すように、テーブル名はデータベース名およびスキーマ名で修飾することができます。

create table tickit.public.test (c1) as select * from oldtable;

この例では、tickitはデータベース名、publicはスキーマ名です。このデータベースまたはスキーマが存在しない場合、ステートメントはエラーを返します。

スキーマ名を指定すると、新しいテーブルはそのスキーマ内に作成されます (作成者がスキーマにアクセス権を持っている場合)。テーブル名は、そのスキーマで一意の名前にする必要があります。スキーマを指定しない場合、現在のデータベーススキーマを使用してテーブルが作成されます。一時テーブルを作成する場合、一時テーブルは特殊なスキーマにあるのでスキーマ名を指定することはできません。

同じ名前の一時テーブルでも、別のセッションで作成される場合、同じデータベース内に同時に存在することができます。このようなテーブルは別のスキーマに割り当てられます。

column_name

新しいテーブルの列の名前。列名を指定しない場合、列名には、クエリの出力列名が使用されます。式にはデフォルトの列名が使用されます。有効な名前の詳細については、「名前と識別子」を参照してください。

BACKUP { YES | NO }

テーブルを自動および手動クラスター スナップショットに含めるかどうかを指定する句。重要なデータを含まないステージング テーブルなどのテーブルについては、スナップショットの作成やスナップショットからの復元にかかる時間を節約し、Amazon Simple Storage Service のストレージスペースを節約するため、BACKUP NO を指定します。BACKUP NO の設定は、クラスター内の別ノードへのデータの自動レプリケーションには影響しません。そのため、BACKUP NO が指定されたテーブルはノードの障害時に回復されます。デフォルトは BACKUP YES です。

DISTSTYLE { AUTO | EVEN | KEY | ALL }

テーブル全体のデータディストリビューションスタイルを定義します。Amazon Redshift は、テーブルに指定されたディストリビューションスタイルに従って、テーブルの行をコンピューティングノードに分散します。デフォルトは DISTSTYLE AUTO です。

テーブルにどの分散スタイルを選択するかによって、データベースの全体的なパフォーマンスが左右されます。詳細については、「データディストリビューションスタイルの操作」を参照してください。

  • AUTO: Amazon Redshift がテーブルデータに基づいて最適な分散スタイルを割り当てます。テーブルに適用された分散スタイルを表示するには、PG_CLASS システムカタログテーブルに対してクエリを実行します。詳細については、「分散スタイルの表示」を参照してください。

  • EVEN: テーブルのデータは、ラウンドロビン分散方式で、クラスター内のノード全体に均等に分散されます。行 ID は分散を決定するために使用され、およそ同じ行数が各ノードに分散されます。これはデフォルトの分散方法です。

  • KEY: データは、DISTKEY 列の値で分散されます。結合するテーブルの結合列を分散キーとして設定すると、両方のテーブルの結合列がコンピューティングノードによりコロケーションされます。データがコロケーションされることで、オプティマイザーはより効率的に結合を実行できます。DISTSTYLE KEY を指定する場合、DISTKEY 列を指定する必要があります。

  • ALL: テーブル全体のコピーがすべてのノードに分散されます。この分散方式により、結合に必要なすべての列が確実にすべてのノードで使用可能になりますが、ストレージ要件が倍増し、テーブルに関する負荷とメンテナンス時間が増大します。ALL 分散を指定する場合、KEY 分散が適さない特定のディメンションテーブルで使用する場合には実行時間が改善される可能性がありますが、パフォーマンスの改善とメンテナンスコストを比較検討する必要があります。

DISTKEY (column)

分散キーの列名または位置番号を指定します。テーブルのオプションの列リストまたはクエリの選択したリストで指定された名前を使用します。または、位置番号を使用します。この番号は、最初に選択された列は 1、2 番目は 2 などと続きます。テーブル内の 1 つの列のみを分散キーに指定できます。

  • 列を DISTKEY 列として宣言する場合、DISTSTYLE を KEY に設定するか、まったく設定しない必要があります。

  • DISTKEY 列を宣言しない場合、DISTSTYLE を EVEN に設定することができます。

  • DISTKEY または DISTSTYLE を指定しない場合、CTAS は SELECT 句のクエリプランに基づいて新しいテーブルの分散スタイルを決定します。詳細については、「列属性とテーブル属性の継承」を参照してください。

同じ列を分散キーおよびソートキーとして定義できます。この方法の場合、該当する列をクエリで結合する列にすると、結合が高速になる傾向があります。

[ COMPOUND | INTERLEAVED ] SORTKEY ( column_name [, ... ] )

テーブルに対して 1 つ以上のソートキーを指定します。データをテーブルにロードすると、データはソートキーとして指定された列に従ってソートされます。

オプションでソート方式として COMPOUND または INTERLEAVED を指定できます。デフォルトは COMPOUND です。詳細については、「ソートキーの使用」を参照してください。

1 つのテーブルで最大 400 の COMPOUND SORTKEY 列または 8 の INTERLEAVED SORTKEY 列を定義できます。

SORTKEY を指定しない場合、CTAS は SELECT 句のクエリプランに基づいて新しいテーブルのソートキーを決定します。詳細については、「列属性とテーブル属性の継承」を参照してください。

COMPOUND

リストされているすべての列から成る複合キーを使用して、データがリスト順にソートされるように指定します。複合ソートキーは、クエリがソート列の順序に従って行をスキャンする場合に最も便利です。複合キーを使用したソートのパフォーマンス上のメリットは、クエリがセカンダリソート列に依存する状況が減少する点にあります。1 つのテーブルで、最大 400 の COMPOUND SORTKEY 列を定義できます。

INTERLEAVED

インターリーブソートキーを使用してデータがソートされるように指定します。インターリーブソートキーには、最大 8 つの列を指定できます。

インターリーブソートは、ソートキーの各列または列のサブセットに等しい重みを割り当てるため、クエリはソートキーの列の順序に依存しません。クエリが 1 つ以上のセカンダリソート列を使用すると、インターリーブソートによってクエリのパフォーマンスは大幅に向上します。インターリーブソートでは、データのロード操作とバキューム操作にわずかなオーバーヘッドコストがかかります。

AS query

Amazon Redshift がサポートするすべてのクエリ (SELECT ステートメント)。