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/). # Compactação de colunas para reduzir o tamanho dos dados armazenados A *compactação* é uma operação em nível de coluna que reduz o tamanho dos dados quando eles são armazenados. A compactação economiza espaço de armazenamento e reduz o tamanho dos dados que são lidos a partir do armazenamento, que reduz a quantidade de E/S de disco e, portanto, melhora a performance da consulta. ENCODE AUTO é o padrão para tabelas. Quando a tabela é definida como ENCODE AUTO, o Amazon Redshift gerencia automaticamente a codificação de compactação para todas as colunas da tabela. Para obter mais informações, consulte [CRIAR TABELA](r_CREATE_TABLE_NEW.md) e [ALTER TABLE](r_ALTER_TABLE.md). Porém, se você especificar a codificação de compactação para qualquer coluna da tabela, a tabela não será mais definida como ENCODE AUTO. O Amazon Redshift não gerencia mais automaticamente a codificação de compactação para todas as colunas da tabela. Você pode aplicar um tipo de compactação ou *codificação* para as colunas em uma tabela manualmente quando você cria a tabela. Ou pode usar o comando COPY para analisar e aplicar compactação automaticamente. Para obter mais informações, consulte [Permitir que COPY selecione as codificações de compactação](c_best-practices-use-auto-compression.md). Para obter detalhes sobre a aplicação de compactação automática, consulte [Carregamento de tabelas com compactação automática](c_Loading_tables_auto_compress.md). **nota** Recomendamos o uso do comando COPY para aplicar a compactação automática. Você pode optar por aplicar codificações de compactação manualmente se a nova tabela compartilhar as mesmas características de dados que outra tabela. Ou pode fazê-lo se ao testar você descobrir que as codificações de compactação aplicadas durante a compactação automática não são a melhor opção para seus dados. Se você escolher aplicar as codificações de compactação manualmente, poderá executar o comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) em uma tabela já povoada e usar os resultados para escolher as codificações de compactação. Para aplicar a compactação manualmente, especifique as codificações de compactação para colunas individuais como parte da instrução CREATE TABLE. A sintaxe é a seguinte. ``` CREATE TABLE table_name (column_name data_type ENCODE encoding-type)[, ...] ``` Aqui, *encoding-type* é retirado da tabela de palavras-chave na seção a seguir. Por exemplo, a seguinte instrução cria uma tabela de duas colunas, PRODUCT. Quando os dados são carregados na tabela, a coluna PRODUCT\$1ID não é compactada, mas a coluna de PRODUCT\$1NAME é compactada usando a codificação do dicionário de bytes (BYTEDICT). ``` create table product( product_id int encode raw, product_name char(20) encode bytedict); ``` Você pode especificar a codificação para uma coluna quando ela é adicionada a uma tabela usando o comando ALTER TABLE. ``` ALTER TABLE table-name ADD [ COLUMN ] column_name column_type ENCODE encoding-type ``` **Topics** + [Codificações de compactação](c_Compression_encodings.md) + [Teste de codificações de compactação](t_Verifying_data_compression.md) # Codificações de compactação Uma *codificação de compactação* especifica o tipo de compactação que é aplicado a uma coluna de valores de dados conforme as linhas são adicionadas a uma tabela. ENCODE AUTO é o padrão para tabelas. Quando a tabela é definida como ENCODE AUTO, o Amazon Redshift gerencia automaticamente a codificação de compactação para todas as colunas da tabela. Para obter mais informações, consulte [CRIAR TABELA](r_CREATE_TABLE_NEW.md) e [ALTER TABLE](r_ALTER_TABLE.md). Porém, se você especificar a codificação de compactação para qualquer coluna da tabela, a tabela não será mais definida como ENCODE AUTO. O Amazon Redshift não gerencia mais automaticamente a codificação de compactação para todas as colunas da tabela. Quando você usa CREATE TABLE, ENCODE AUTO é desativada ao especificar a codificação de compactação para qualquer coluna da tabela. Se ENCODE AUTO estiver desativada, o Amazon Redshift atribuirá automaticamente uma codificação de compactação a colunas para as quais você não especificar um tipo ENCODE, 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 ou DOUBLE PRECISION recebem a compactação RAW. + As colunas definidas como tipos de dados SMALLINT, INTEGER, BIGINT, DECIMAL, DATE, TIMESTAMP ou TIMESTAMPTZ recebem a compactação AZ64. + As colunas definidas como tipos de dados CHAR ou VARCHAR recebem a compactação LZO. Você pode alterar a codificação de uma tabela depois de criá-la usando ALTER TABLE. Se você desabilitar ENCODE AUTO usando ALTER TABLE, o Amazon Redshift deixará de gerenciar automaticamente as codificações de compactação de suas colunas. Todas as colunas manterão os tipos de codificação de compactação que tinham quando você desativou ENCODE AUTO até que sejam alteradas ou até que ENCODE AUTO seja reativada. O Amazon Redshift permite as seguintes codificações de compactação: ------ #### [ Raw ] A codificação raw é a codificação padrão para as colunas que são designadas como chaves de classificação e colunas definidas como tipo de dados BOOLEAN, REAL ou DOUBLE PRECISION. Com a codificação raw, os dados são armazenados em formato bruto, descompactado. ------ #### [ AZ64 ] AZ64 é um algoritmo de codificação de compactação proprietário projetado pela Amazon para atingir uma alta taxa de compactação e processamento de consulta aprimorado. No seu núcleo, o algoritmo AZ64 compacta grupos menores de valores de dados e usa instruções SIMD (Single Instruction, Multiple Data – instrução única, vários dados) para processamento paralelo. Use o AZ64 para obter uma economia significativa de armazenamento e alta performance para tipos de dados numéricos, de data e hora. É possível usar o AZ64 como a codificação de compactação ao definir colunas com as instruções CREATE TABLE e ALTER TABLE com os seguintes tipos de dados: + SMALLINT + INTEGER + BIGINT + DECIMAL + DATE + TIMESTAMP + TIMESTAMPTZ ------ #### [ Byte-dictionary ] Na codificação do dicionário de bytes, um dicionário separado de valores exclusivos é criado para cada bloco de valores de coluna em disco. (Um bloco de disco do Amazon Redshift ocupa 1 MB.) O dicionário contém até 256 valores de um byte que são armazenados como índices para os valores de dados originais. Se mais do que 256 valores forem armazenados em um único bloco, os valores adicionais serão gravados no bloco em formato bruto, descompactado. O processo é repetido para cada bloco de disco. Essa codificação é muito eficaz em colunas de strings de baixa cardinalidade. Esta codificação é ótima quando o domínio de dados de uma coluna é menor do que 256 valores exclusivos. Para colunas com o tipo de dado string (CHAR e VARCHAR) codificado com BYTEDICT, o Amazon Redshift executa varreduras vetorizadas e avaliações de predicados que operam diretamente sobre dados compactados. Essas varreduras usam instruções SIMD (instrução única, vários dados) específicas do hardware para processamento paralelo. Isso acelera significativamente a varredura de colunas de strings. A codificação do dicionário de bytes é especialmente eficiente em termos de espaço se uma coluna CHAR/VARCHAR contém strings de caracteres longas. Suponha que uma tabela tenha uma coluna COUNTRY com um tipo de dados CHAR(30). Conforme os dados são carregados, o Amazon Redshift cria o dicionário e preenche a coluna COUNTRY com o valor do índice. O dicionário contém os valores exclusivos indexados e a tabela em si contém somente as subscrições de um byte dos valores correspondentes. **nota** Os espaços em branco são armazenados para colunas de caracteres de comprimento fixo. Portanto, em uma coluna CHAR(30), cada valor compactado economiza 29 bytes de armazenamento quando você usa a codificação do dicionário de bytes. A tabela a seguir representa o dicionário para a coluna COUNTRY. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/c_Compression_encodings.html) A tabela a seguir representa os valores na coluna COUNTRY. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/c_Compression_encodings.html) O tamanho total compactado neste exemplo é calculado da seguinte forma: 6 entradas diferentes são armazenadas no dicionário (6 x 30 = 180) e a tabela contém 10 valores de 1 byte compactados, totalizando 190 bytes. ------ #### [ Delta ] As codificações delta são muito úteis para colunas de data e hora. A codificação delta compacta dados registrando a diferença entre os valores que se seguem na coluna. Essa diferença é registrada em um dicionário separado para cada bloco de valores da coluna em disco. (Um bloco de disco do Amazon Redshift ocupa 1 MB.) Por exemplo, suponha que a coluna contém 10 inteiros em sequência de 1 a 10. Os primeiros são armazenados como um inteiro de 4 bytes (mais um sinalizador de 1 byte). Os próximos nove são armazenados como um byte com o valor 1, indicando que é um maior do que o valor anterior. A codificação delta vem em duas variações: + DELTA registra as diferenças como valores de 1 byte (inteiros 8 bits) + DELTA32K registra as diferenças como valores de 2 bytes (inteiros 16 bits) Se a maioria dos valores na coluna podem ser compactados usando um único byte, a variação de 1 byte é muito eficaz. No entanto, se os deltas forem maiores, essa codificação, na pior das hipóteses, é um pouco menos eficaz do que o armazenamento de dados descompactados. Uma lógica similar se aplica à versão de 16 bits. Se a diferença entre dois valores exceder o intervalo de 1 byte (DELTA) ou o intervalo de 2 bytes (DELTA32K), o valor original total é armazenado com um sinalizador de 1 byte. O intervalo de 1 byte é de -127 a 127 e o intervalo de 2 bytes é de -32K a 32K. A tabela a seguir mostra como uma codificação delta funciona para uma coluna numérica: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ LZO ] A codificação LZO fornece uma taxa de compactação bastante elevada com boa performance. A codificação LZO funciona particularmente bem para as colunas CHAR e VARCHAR que armazenam strings de caracteres muito longas. Elas são especialmente boas para texto de formato livre, tais como descrições de produto, comentários de usuários ou strings JSON. ------ #### [ Mostly ] Codificações mostly são úteis quando o tipo de dados de uma coluna é maior do que a maioria dos valores armazenados exige. Ao especificar uma codificação mostly para esse tipo de coluna, você pode compactar a maioria dos valores na coluna para um tamanho menor de armazenamento padrão. Os valores restantes que não podem ser compactados são armazenados na forma bruta. Por exemplo, você pode compactar uma coluna de 16 bits, tal como uma coluna INT2, para um armazenamento de 8 bits. Geralmente, as codificações mostly funcionam com os seguintes tipos de dados: + SMALLINT/INT2 (16 bits) + INTEGER/INT (32 bits) + BIGINT/INT8 (64 bits) + DECIMAL/NUMERIC (64 bits) Escolha a variação apropriada da codificação mostly para atender ao tamanho do tipo de dado para a coluna. Por exemplo, aplique MOSTLY8 a uma coluna que seja definida como uma coluna de inteiros de 16 bits. A aplicação de MOSTLY16 a uma coluna com um tipo de dados de 16 bits ou MOSTLY32 a uma coluna com um tipo de dados de 32 bits não é autorizada. As codificações mostly podem ser menos eficazes do que nenhuma compactação quando um número relativamente alto de valores na coluna não pode ser compactado. Antes de aplicar uma dessas codificações a uma coluna, execute uma verificação. A *maioria* dos valores que você pretende carregar agora (e prováveis futuros carregamentos) devem caber nos intervalos exibidos na seguinte tabela. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/c_Compression_encodings.html) **nota** Para valores decimais, ignore o ponto decimal para determinar se o valor se enquadra no intervalo. Por exemplo, 1.234,56 é tratado como 123.456 e pode ser compactado em uma coluna MOSTLY32. Por exemplo, a coluna VENUEID na tabela VENUE é definida como uma coluna de inteiros brutos, o que significa que seus valores consomem 4 bytes de armazenamento. Contudo, o atual intervalo de valores na coluna é de **0** a **309**. Portanto, recriar e recarregar essa tabela com a codificação MOSTLY16 para VENUEID reduziria o armazenamento de cada valor nessa coluna para 2 bytes. Se os valores de VENUEID referenciados em outra tabela estavam sobretudo no intervalo de 0 a 127, pode fazer sentido codificar essa coluna de chave estrangeira como MOSTLY8. Antes de fazer a escolha, execute várias consultas nos dados da tabela de referência para descobrir se os valores caem principalmente no intervalo de 8 bits, 16 bits ou 32 bits. A tabela a seguir mostra os tamanhos compactados para valores numéricos específicos quando as codificações MOSTLY8, MOSTLY16 e MOSTLY32 são usadas: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Run length ] A execução de codificação de comprimento substitui um valor que é repetido consecutivamente por um token que consiste no valor e uma contagem do número de ocorrências consecutivas (a duração da execução). Um dicionário separado de valores exclusivos é criado para cada bloco de valores de coluna em disco. (Um bloco de disco do Amazon Redshift ocupa 1 MB.) Esta codificação é mais apropriada para uma tabela na qual os valores de dados são frequentemente repetidos consecutivamente, por exemplo, quando a tabela é classificada por esses valores. Por exemplo, suponha que uma coluna em uma tabela de grande dimensão tenha um domínio previsivelmente pequeno, como uma coluna COLOR com menos de 10 valores possíveis. Esses valores provavelmente cairão em longas sequências em toda a tabela, mesmo que os dados não sejam classificados. Não recomendamos aplicar a codificação de comprimento de execução em qualquer coluna designada como uma chave de classificação. Varreduras de intervalo restrito têm melhor performance quando os blocos contêm números semelhantes de linhas. Se as colunas de chave de classificação forem mais altamente compactadas do que outras colunas na mesma consulta, varreduras restritas por intervalo poderão apresentar má performance. A tabela a seguir usa o exemplo da coluna COLOR para mostrar como funciona a codificação de comprimento de execução. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/c_Compression_encodings.html) ------ #### [ Text255 and Text32k ] As codificações text255 e text32k são úteis para a compactação de colunas VARCHAR nas quais as mesmas palavras se repetem com frequência. Um dicionário separado de palavras exclusivas é criado para cada bloco de valores de coluna em disco. (Um bloco de disco do Amazon Redshift ocupa 1 MB.) O dicionário contém as primeiras 245 palavras exclusivas na coluna. Essas palavras são substituídas em disco por um valor de índice de um byte que representa um dos 245 valores e todas as palavras que não estão representadas no dicionário são armazenadas descompactadas. O processo é repetido para cada bloco de disco de 1 MB. Se as palavras indexadas ocorrerem com frequência na coluna, a coluna produzirá uma alta taxa de compactação. Para a codificação text32k, o princípio é o mesmo, mas o dicionário para cada bloco não captura um número específico de palavras. Em vez disso, o dicionário indexa cada palavra exclusiva que ele encontra até que as entradas combinadas atinjam o comprimento de 32K, menos alguma sobrecarga. Os valores dos índices são armazenados em dois bytes. Por exemplo, considere a coluna VENUENAME na tabela VENUE. Palavras como **Arena**, **Center** e **Theatre** são repetidas nesta coluna e provavelmente estão entre as primeiras 245 palavras encontradas em cada bloco se a compactação text255 é aplicada. Em caso afirmativo, esta coluna se beneficia da compactação. Isso ocorre porque sempre que essas palavras aparecem, elas ocupam apenas 1 byte de armazenamento (em vez de 5, 6 ou 7 bytes, respectivamente). ------ #### [ ZSTD ] A codificação Zstandard (ZSTD) fornece uma alta taxa de compactação com performance muito boa ao longo de diversos conjuntos de dados. ZSTD funciona particularmente bem com colunas CHAR e VARCHAR que armazenam uma grande variedade de strings longas e curtas, tais como descrições de produto, comentários de usuários, logs e strings JSON. Embora seja possível que alguns algoritmos, como a codificação Delta ou Mostly, usem mais espaço de armazenamento do que a opção sem compactação, é improvável que a codificação ZSTD aumente o uso de disco. ZSTD é compatível com os tipos de dados SMALLINT, INTEGER, BIGINT, DECIMAL, REAL, DOUBLE PRECISION, BOOLEAN, CHAR, VARCHAR, DATE, TIMESTAMP e TIMESTAMPTZ. ------ A tabela a seguir identifica as codificações de compactação compatíveis e os tipos de dados compatíveis com a codificação. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/redshift/latest/dg/c_Compression_encodings.html) # Teste de codificações de compactação Se você decidir especificar codificações de coluna manualmente, talvez queira testar diferentes codificações com seus dados. **nota** Recomendamos que você use o comando COPY para carregar dados sempre que possível, permitindo que o comando COPY escolha as codificações ideais com base em seus dados. Como alternativa, você pode usar o comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) para visualizar as codificações sugeridas para os dados existentes. Para obter detalhes sobre a aplicação de compactação automática, consulte [Carregamento de tabelas com compactação automática](c_Loading_tables_auto_compress.md). Para executar um teste significativo de compactação de dados, é necessário ter um grande número de linhas. Para este exemplo, criamos uma tabela e inserimos linhas usando uma instrução que seleciona a partir de duas tabelas; VENUE e LISTING. Deixamos de fora a cláusula WHERE que normalmente uniria as duas tabelas. O resultado é que *cada* linha da tabela VENUE é unida a *todas* as linhas da tabela LISTING, para um total de mais de 32 milhões de linhas. Isso é conhecido como uma junção cartesiana e não é normalmente recomendado. No entanto, para esta finalidade, é um método conveniente para criar muitas linhas. Se você tiver uma tabela existente com dados que deseja testar, poderá ignorar esta etapa. Depois de termos uma tabela com dados de amostra, criamos uma tabela com sete colunas. Cada um tem uma codificação de compactação diferente: raw, bytedict, lzo, run length, text255, text32k e zstd. Preenchemos cada coluna com exatamente os mesmos dados, executando um comando INSERT que seleciona os dados da primeira tabela. Para testar codificações de compactação, faça o seguinte: 1. (Opcional) Primeiro, use uma junção cartesiana para criar uma tabela com um grande número de linhas. Ignore esta etapa se você deseja testar uma tabela existente. ``` create table cartesian_venue( venueid smallint not null distkey sortkey, venuename varchar(100), venuecity varchar(30), venuestate char(2), venueseats integer); insert into cartesian_venue select venueid, venuename, venuecity, venuestate, venueseats from venue, listing; ``` 1. Em seguida, crie uma tabela com as codificações que deseja comparar. ``` create table encodingvenue ( venueraw varchar(100) encode raw, venuebytedict varchar(100) encode bytedict, venuelzo varchar(100) encode lzo, venuerunlength varchar(100) encode runlength, venuetext255 varchar(100) encode text255, venuetext32k varchar(100) encode text32k, venuezstd varchar(100) encode zstd); ``` 1. Insira os mesmos dados em todas as colunas usando uma instrução INSERT com uma cláusula SELECT. ``` insert into encodingvenue select venuename as venueraw, venuename as venuebytedict, venuename as venuelzo, venuename as venuerunlength, venuename as venuetext32k, venuename as venuetext255, venuename as venuezstd from cartesian_venue; ``` 1. Verifique o número de linhas na nova tabela. ``` select count(*) from encodingvenue count ---------- 38884394 (1 row) ``` 1. Consulte a tabela de sistema [STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) para comparar o número de blocos de disco de 1 MB usados por cada coluna. A função de agregação MAX retorna o número de bloco mais alto para cada coluna. A tabela STV\$1BLOCKLIST inclui detalhes para as três colunas geradas pelo sistema. Este exemplo usa `col < 6` na cláusula WHERE para excluir as colunas geradas pelo sistema. ``` select col, max(blocknum) from stv_blocklist b, stv_tbl_perm p where (b.tbl=p.id) and name ='encodingvenue' and col < 7 group by name, col order by col; ``` A consulta retorna os seguintes resultados. As colunas são numeradas a partir de zero. Dependendo de como seu cluster está configurado, o resultado pode ter números diferentes, mas os tamanhos relativos devem ser similares. Você pode ver que a codificação BYTEDICT na segunda coluna produziu os melhores resultados para este conjunto de dados. Essa abordagem tem uma taxa de compactação de melhor que 20:1. As codificações LZO e ZSTD também produziram excelentes resultados. É evidente que diferentes conjuntos de dados produzem resultados diferentes. Quando uma coluna contém strings de texto mais longas, a codificação LZO frequentemente produz os melhores resultados de compactação. ``` col | max -----+----- 0 | 203 1 | 10 2 | 22 3 | 204 4 | 56 5 | 72 6 | 20 (7 rows) ``` Se você tiver dados em uma tabela existente, será possível usar o comando [ANALYZE COMPRESSION](r_ANALYZE_COMPRESSION.md) para visualizar as codificações sugeridas para a tabela. Por exemplo, o seguinte exemplo mostra a codificação recomendada para uma cópia da tabela VENUE, CARTESIAN\$1VENUE, que contém 38 milhões de linhas. Observe que ANALYZE COMPRESSION recomenda a codificação LZO para a coluna VENUENAME. ANALYZE COMPRESSION escolhe a compactação ideal com base em diversos fatores, incluindo a porcentagem de redução. Neste caso específico, BYTEDICT fornece a melhor compactação, mas LZO também produz uma compactação maior que 90 por cento. ``` analyze compression cartesian_venue; Table | Column | Encoding | Est_reduction_pct ---------------+------------+----------+------------------ reallybigvenue | venueid | lzo | 97.54 reallybigvenue | venuename | lzo | 91.71 reallybigvenue | venuecity | lzo | 96.01 reallybigvenue | venuestate | lzo | 97.68 reallybigvenue | venueseats | lzo | 98.21 ``` ## Exemplo O seguinte exemplo cria uma tabela CUSTOMER que tem colunas com vários tipos de dados. Esta instrução CREATE TABLE mostra uma das muitas combinações possíveis de codificações para essas colunas. ``` create table customer( custkey int encode delta, custname varchar(30) encode raw, gender varchar(7) encode text255, address varchar(200) encode text255, city varchar(30) encode text255, state char(2) encode raw, zipcode char(5) encode bytedict, start_date date encode delta32k); ``` A tabela a seguir mostra as codificações de coluna que foram escolhidas para a tabela CUSTOMER, fornecendo uma explicação para as escolhas: | Coluna | Tipo de dados | Codificação | Explicação | | --- | --- | --- | --- | | CUSTKEY | int | delta | CUSTKEY consiste em valores inteiros consecutivos exclusivos. Como as diferenças são de um byte, DELTA é uma boa escolha. | | CUSTNAME | varchar(30) | bruto | CUSTNAME tem um grande domínio com poucos valores repetidos. Qualquer codificação de compactação seria provavelmente ineficaz. | | GENDER | varchar(7) | text255 | GENDER é um domínio muito pequeno com muitos valores repetidos. Text255 funciona perfeitamente com colunas VARCHAR nas quais as mesmas palavras se repetem. | | ADDRESS | varchar(200) | text255 | ADDRESS é um grande domínio, mas contém muitas palavras repetidas, como rua, avenida, Norte, Sul etc. Text 255 e text 32k são úteis para a compactação de colunas VARCHAR nas quais as mesmas palavras se repetem. O tamanho de coluna é curto, portanto text255 é uma boa escolha. | | CITY | varchar(30) | text255 | CITY é um grande domínio, com alguns valores repetidos. Determinados nomes de cidade são usados muito mais comumente do que outros. Text255 é uma boa escolha pelos mesmos motivos que ADDRESS. | | STATE | char(2) | bruto | Nos Estados Unidos, STATE é um domínio preciso de 50 valores de dois caracteres. A codificação Bytedict produziria alguma compactação, mas como o tamanho da coluna é de somente dois caracteres, a compactação pode não compensar o custo da descompactação dos dados. | | ZIPCODE | char(5) | bytedict | ZIPCODE é um domínio conhecido de pouco mais que 50.000 valores exclusivos. Determinados códigos postais ocorrem muito mais comumente do que outros. A codificação bytedict é muito eficaz quando uma coluna contém um número limitado de valores exclusivos. | | START\$1DATE | date | delta32k | Codificações delta são muito úteis para colunas de data e hora, especialmente se as linhas são carregadas em ordem de data. |