O Amazon Redshift não permitirá mais a criação de UDFs do Python a partir do Patch 198. As UDFs do Python existentes continuarão a funcionar normalmente até 30 de junho de 2026. Para ter mais informações, consulte a [publicação de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
# Observações de uso CTAS
## Limites
O Amazon Redshift impõe uma cota do número de tabelas por cluster por tipo de nó.
O número máximo de caracteres para um nome de tabela é 127.
O número máximo de colunas que você pode definir em uma única tabela é 1.600.
## Herança de atributos de coluna e tabela
Tabelas CREATE TABLE AS (CTAS) não herdam restrições, colunas de identidade, valores de coluna padrão ou a chave primária da tabela com base na qual foram criadas.
Você não pode especificar codificações de compactação de coluna para tabelas CTAS. O Amazon Redshift atribui automaticamente a codificação de compactação da seguinte maneira:
+ Colunas que são definidas como chaves de classificação são designadas a compactação RAW.
+ Colunas que são definidas como tipos de dados BOOLEAN, REAL, DOUBLE PRECISION, GEOMETRY ou GEOGRAPHY recebem a compactação RAW.
+ As colunas definidas como SMALLINT, INTEGER, BIGINT, DECIMAL, DATE, TIME, TIMETZ, TIMESTAMP ou TIMESTAMPTZ recebem a compactação AZ64.
+ As colunas definidas como CHAR, VARCHAR ou VARBYTE recebem a compactação LZO.
Para obter mais informações, consulte [Codificações de compactação](c_Compression_encodings.md) e [Tipos de dados](c_Supported_data_types.md).
Para atribuir explicitamente codificações de coluna, use [CRIAR TABELA](r_CREATE_TABLE_NEW.md).
O CTAS determina o estilo de distribuição e a chave de classificação para a nova tabela com base no plano de consulta para a cláusula SELECT.
Para consultas complexas, como consultas incluindo junções, agregações, classificação por cláusula ou uma cláusula de limite, o CTAS se esforça para escolher o melhor estilo de distribuição e chave de classificação com base no plano de consulta.
**nota**
Para uma melhor performance com grandes conjuntos de dados ou consultas complexas, recomendamos testar usando conjuntos de dados típicos.
Muitas vezes você pode prever qual chave de distribuição e chave de classificação o CTAS escolhe examinando o plano de consulta para ver quais colunas, se houver, o otimizador de consulta escolherá para classificação e distribuição de dados. Se o nó superior do plano de consulta for uma varredura sequencial simples de uma tabela única (XN Seq Scan), o CTAS usará o estilo de distribuição e a chave de classificação da tabela de origem. Se o nó superior do plano de consulta for qualquer outra varredura sequencial (como XN Limit, XN Sort, XN HashAggregate, etc.), o CTAS se esforça para escolher o melhor estilo de distribuição e chave de classificação com base no plano de consulta.
Por exemplo, suponhamos que você crie cinco tabelas usando os seguintes tipos de cláusulas SELECT:
+ Um instrução simples de seleção
+ Uma cláusula de limitação
+ Um classificação por cláusula usando LISTID
+ Um classificação por cláusula usando QTYSOLD
+ Uma função agregada SUM com um agrupamento por cláusula.
Os exemplos a seguir mostram o plano de consulta para cada comando CTAS.
```
explain create table sales1_simple as select listid, dateid, qtysold from sales;
QUERY PLAN
----------------------------------------------------------------
XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(1 row)
explain create table sales2_limit as select listid, dateid, qtysold from sales limit 100;
QUERY PLAN
----------------------------------------------------------------------
XN Limit (cost=0.00..1.00 rows=100 width=8)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(2 rows)
explain create table sales3_orderbylistid as select listid, dateid, qtysold from sales order by listid;
QUERY PLAN
------------------------------------------------------------------------
XN Sort (cost=1000000016724.67..1000000017155.81 rows=172456 width=8)
Sort Key: listid
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(3 rows)
explain create table sales4_orderbyqty as select listid, dateid, qtysold from sales order by qtysold;
QUERY PLAN
------------------------------------------------------------------------
XN Sort (cost=1000000016724.67..1000000017155.81 rows=172456 width=8)
Sort Key: qtysold
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(3 rows)
explain create table sales5_groupby as select listid, dateid, sum(qtysold) from sales group by listid, dateid;
QUERY PLAN
----------------------------------------------------------------------
XN HashAggregate (cost=3017.98..3226.75 rows=83509 width=8)
-> XN Seq Scan on sales (cost=0.00..1724.56 rows=172456 width=8)
(2 rows)
```
Para exibir a chave de distribuição e a chave de classificação para cada tabela, consulte a tabela de catálogo de sistema PG\$1TABLE\$1DEF, como mostrado a seguir.
```
select * from pg_table_def where tablename like 'sales%';
tablename | column | distkey | sortkey
----------------------+------------+---------+---------
sales | salesid | f | 0
sales | listid | t | 0
sales | sellerid | f | 0
sales | buyerid | f | 0
sales | eventid | f | 0
sales | dateid | f | 1
sales | qtysold | f | 0
sales | pricepaid | f | 0
sales | commission | f | 0
sales | saletime | f | 0
sales1_simple | listid | t | 0
sales1_simple | dateid | f | 1
sales1_simple | qtysold | f | 0
sales2_limit | listid | f | 0
sales2_limit | dateid | f | 0
sales2_limit | qtysold | f | 0
sales3_orderbylistid | listid | t | 1
sales3_orderbylistid | dateid | f | 0
sales3_orderbylistid | qtysold | f | 0
sales4_orderbyqty | listid | t | 0
sales4_orderbyqty | dateid | f | 0
sales4_orderbyqty | qtysold | f | 1
sales5_groupby | listid | f | 0
sales5_groupby | dateid | f | 0
sales5_groupby | sum | f | 0
```
A tabela a seguir resume os resultados. Para simplificar, omitimos os custos, as linhas e os detalhes de largura do plano de explicação.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/r_CTAS_usage_notes.html)
Você pode especificar explicitamente o estilo de distribuição e a chave de classificação da instrução CTAS. Por exemplo, a instrução a seguir cria uma tabela usando a distribuição EVEN e especifica SALESID como a chave de classificação.
```
create table sales_disteven
diststyle even
sortkey (salesid)
as
select eventid, venueid, dateid, eventname
from event;
```
## Codificação de compactação
ENCODE AUTO é usado como o padrão para tabelas. O Amazon Redshift gerencia automaticamente a codificação de compactação para todas as colunas da tabela.
## Distribuição de dados de entrada
Quando o esquema de distribuição de hash de dados de entrada corresponder aos dados da tabela de destino, nenhuma distribuição física de dados é realmente necessária quando os dados são carregados. Por exemplo, se uma chave de distribuição for definida para a nova tabela e os dados estiverem sendo introduzidos a partir de outra tabela que é distribuída na mesma coluna chave, os dados serão carregados no local, usando os mesmos nós e fatias. No entanto, se as tabelas de origem e de destino forem definidas com a distribuição EVEN, os dados serão redistribuídos em uma tabela de destino.
## Operações ANALYZE automáticas
O Amazon Redshift analisa automaticamente tabelas criadas com comandos CTAS. Não precisar executar o comando ANALYZE nessas tabelas quando elas são inicialmente criadas. Se você as modificar, você deve analisá-las da mesma forma que outras tabelas.