Hologres:Default behavior changes

V4.2

V4.1

SET password_encryption = 'md5';
ALTER USER "BASIC$user" WITH PASSWORD 'password';

V4.0 (Setembro de 2025)

V3.2 (Agosto de 2026)

• Alteração no número padrão de threads de serviço RPC para consultas a tabelas externas do MaxCompute

  O que mudou: A partir do Hologres V3.2.42, o valor padrão do parâmetro de threads de serviço RPC holo_seahawks_rpc_service_thread_number foi alterado de 300 para 150.

  Impacto: Consultas a tabelas externas do MaxCompute executadas no mecanismo SQE com alto QPS apresentam um aumento moderado na latência. Em contrapartida, a instância opera com mais estabilidade: as consultas a tabelas externas não competem mais pelos recursos das consultas a tabelas internas nem degradam seu desempenho, o que melhora a integridade geral da instância.

  Recomendação: Atualize a instância para o Hologres V4.1 ou posterior. A partir dessa versão, as consultas a tabelas externas são executadas em um novo mecanismo que oferece melhor desempenho de consulta, mantendo a estabilidade.

• Novo limite para o número de arquivos lidos de uma única tabela externa do MaxCompute

  O que mudou: A partir do Hologres V3.2.43, um novo parâmetro GUC hg_experimental_maxcompute_sdk_split_total_file_count_limit foi adicionado, com valor padrão de 100.000. Se uma única tabela externa do MaxCompute ler mais arquivos do que esse limite em uma única consulta, a consulta falhará com um erro. Antes dessa alteração, o parâmetro não existia e o número de arquivos lidos de uma única tabela era ilimitado.

  Impacto: Cargas de trabalho que consultam tabelas externas do MaxCompute, especialmente tabelas que contêm uma grande quantidade de arquivos pequenos. As consultas que excedem o limite são bloqueadas, o que evita que o uso excessivo de memória acione erros de OOM e afete outras cargas de trabalho na instância.

  Recomendação: Primeiro, mescle arquivos pequenos no lado do MaxCompute para reduzir o número de arquivos lidos por cada consulta. Se a mesclagem de arquivos pequenos não for viável no momento, aumente o valor de hg_experimental_maxcompute_sdk_split_total_file_count_limit após avaliar os recursos restantes da instância. Um valor maior eleva a marca d'água de memória da instância. Defina-o de forma conservadora com base na sua carga de trabalho real e continue monitorando o uso de memória após o ajuste.

V3.2 (Julho de 2025)

• Palavras-chave não reservadas como Branch, Overwrite, Parameter e Tag foram adicionadas; palavras-chave reservadas como Lambda e Qualify também foram incluídas. Para obter informações sobre palavras-chave, consulte Palavras-chave do PostgreSQL.

• A partir do Hologres V3.2, a otimização adaptativa para CTEs é suportada. A estratégia de materialização de CTE é determinada por dois parâmetros GUC: optimizer_cte_inlining e hg_cte_strategy. Esses parâmetros são independentes entre si e podem ser definidos separadamente, independentemente da ordem de configuração. Os comportamentos são os seguintes:

  • Quando optimizer_cte_inlining = off, as CTEs são reutilizadas, independentemente da configuração de hg_cte_strategy.

  • Quando optimizer_cte_inlining = on, as CTEs não são mais embutidas (inlined) à força. A política de CTE é determinada por hg_cte_strategy:

    • Se hg_cte_strategy = auto (padrão), o otimizador de consultas (QO) seleciona automaticamente se deve embutir ou reutilizar a CTE com base em fatores como sua complexidade.

    • Quando hg_cte_strategy = inlining, as CTEs são embutidas à força.

    • Quando hg_cte_strategy = reuse, as CTEs são reutilizadas à força.

• A partir do Hologres V3.2, o Fast Rows é ativado por padrão. Quando uma tabela não possui estatísticas, o otimizador obtém automaticamente a contagem real de linhas para gerar um plano de execução melhor.

  Esse comportamento é automático após a atualização e não requer configuração. Para mais detalhes, consulte: {{XREF_14}}.

V3.1 (Agosto de 2026)

• Alteração no número padrão de threads de serviço RPC para consultas a tabelas externas do MaxCompute

  O que mudou: A partir do Hologres V3.1.53, o valor padrão do parâmetro de threads de serviço RPC holo_seahawks_rpc_service_thread_number foi alterado de 300 para 150.

  Impacto: Consultas a tabelas externas do MaxCompute executadas no mecanismo SQE com alto QPS apresentam um aumento moderado na latência. Em contrapartida, a instância opera com mais estabilidade: as consultas a tabelas externas não competem mais pelos recursos das consultas a tabelas internas nem degradam seu desempenho, o que melhora a integridade geral da instância.

  Recomendação: Atualize a instância para o Hologres V4.1 ou posterior. A partir dessa versão, as consultas a tabelas externas são executadas em um novo mecanismo que oferece melhor desempenho de consulta, mantendo a estabilidade.

• Novo limite para o número de arquivos lidos de uma única tabela externa do MaxCompute

  O que mudou: A partir do Hologres V3.1.53, um novo parâmetro GUC hg_experimental_maxcompute_sdk_split_total_file_count_limit foi adicionado, com valor padrão de 100.000. Se uma única tabela externa do MaxCompute ler mais arquivos do que esse limite em uma única consulta, a consulta falhará com um erro. Antes dessa alteração, o parâmetro não existia e o número de arquivos lidos de uma única tabela era ilimitado.

  Impacto: Cargas de trabalho que consultam tabelas externas do MaxCompute, especialmente tabelas que contêm uma grande quantidade de arquivos pequenos. As consultas que excedem o limite são bloqueadas, o que evita que o uso excessivo de memória acione erros de OOM e afete outras cargas de trabalho na instância.

  Recomendação: Primeiro, mescle arquivos pequenos no lado do MaxCompute para reduzir o número de arquivos lidos por cada consulta. Se a mesclagem de arquivos pequenos não for viável no momento, aumente o valor de hg_experimental_maxcompute_sdk_split_total_file_count_limit após avaliar os recursos restantes da instância. Um valor maior eleva a marca d'água de memória da instância. Defina-o de forma conservadora com base na sua carga de trabalho real e continue monitorando o uso de memória após o ajuste.

V3.1 (Maio de 2025)

• Tabelas dinâmicas:

  • Sintaxe

    A partir do Hologres V3.1, as tabelas dinâmicas usam uma nova sintaxe mais concisa. Após a atualização das tabelas dinâmicas criadas na V3.0 para a V3.1, apenas operações ALTER podem ser executadas em uma tabela que usa atualização completa de dados. Para criar uma nova tabela, a nova sintaxe da V3.1 deve ser usada. Para uma tabela que usa atualização incremental de dados, você deve recriar a tabela usando a nova sintaxe. Para obter mais informações, consulte {{XREF_15}}.

  • Uso de recursos

    • Recursos de atualização

      As tabelas dinâmicas criadas no Hologres V3.1 usam recursos de computação serverless por padrão para executar tarefas. Se a instância atual não tiver a Computação Serverless ativada, ela retornará automaticamente aos recursos da instância. As tabelas criadas no Hologres V3.0 continuam a usar os recursos especificados no momento da criação da tabela. Para obter mais informações, consulte {{XREF_16}}.

    • Criação de tabelas usando recursos da instância

      • Nova sintaxe (Hologres V3.1 e V3.2): As virtual warehouses primárias para os grupos de tabelas da tabela base e da tabela dinâmica são utilizadas.

      • Sintaxe antiga (Hologres V3.0) e nova sintaxe (Hologres V4.1): A virtual warehouse primária para o grupo de tabelas da tabela dinâmica é utilizada.

  • Contagem de conexões

    A nova sintaxe mantém uma conexão adicional por tabela dinâmica. Se a sua instância tiver alta utilização de conexões e centenas de tabelas dinâmicas, remova as conexões ociosas para evitar problemas.

  • Métodos para leitura de dados incrementais da tabela base

    A partir do Hologres V3.1 e posterior, o método de stream é usado para identificar alterações de dados na tabela base. Em comparação com o binary logging, o método de stream tem maior desempenho e é mais econômico. Após a atualização da sua instância para a V3.1, o método de stream é usado por padrão. Se o binary logging estiver ativado para a sua tabela na V3.0, desative-o prontamente para evitar custos extras de armazenamento. Para obter mais informações, consulte {{XREF_17}}.

• O recurso de fila de consultas concluiu a fase Beta e está disponível para uso em produção. Para obter mais informações, consulte {{XREF_18}}.

• O TRUNCATE agora é uma instrução DML (antes DDL), reduzindo a pressão no nó FE. Para reverter para o comportamento DDL, desative o parâmetro GUC hg_enable_truncate_as_dml. No entanto, ao executar uma operação TRUNCATE em uma tabela com binary logging ativado, você precisa desativar o binary logging no nível da sessão. Para obter mais informações, consulte {{XREF_19}}.

• Ao importar dados para uma tabela com chave primária usando COPY, o parâmetro GUC hg_experimental_copy_enable_on_conflict é ativado por padrão. Isso permite definir políticas de atualização de dados ao importar dados para tabelas com chaves primárias. Para obter mais informações, consulte {{XREF_20}}.

• Ao usar o recurso hg_insert_overwrite, o número de colunas e seus tipos de dados especificados na instrução SQL (instrução SELECT padrão) devem corresponder estritamente aos da tabela de destino (tabela interna do Hologres). Caso contrário, a mensagem de erro error: table "hg_alias" has x columns available but x columns specified ou error: column xx is of type xxx but expression is of type xxx será relatada. Para obter mais informações, consulte {{XREF_21}}.

• A tabela do sistema hg_table_storage_status foi atualizada. A partir do Hologres V3.1, a tabela do sistema não inclui mais os dados da tabela armazenados na memória (tabela de memória). Em vez disso, ela reflete apenas o armazenamento físico real das tabelas. Para obter mais informações sobre o mecanismo de tabela de memória, consulte {{XREF_22}}.

• Palavras-chave não reservadas adicionadas: async, logical, purge, recover, rebuild, resume e suspend. Consulte Palavras-chave do PostgreSQL.

V3.0

WHERE (pk1 = 1 AND pk2 = 1) OR (pk1 = 2 AND pk2 = 2) OR (pk1 = 3 AND pk2 = 3)-- The number of combinations in this example is 3.
    
WHERE pk1 IN (1, 2, 3) AND pk2 IN (1,2,3)-- The number of combinations in this example is 9. Formula: 3 × 3 = 9.

V2.2

V2.2 (Julho de 2024)

Ao usar Java Database Connectivity (JDBC) para consumir binary logs do Hologres, o número máximo de walsenders disponíveis para um worker é reduzido de 1.000 para 600. O número de walsenders é calculado pelo número de slots. Para obter mais informações, consulte {{XREF_25}}. Recomendamos o uso do modo jdbc_fixed para consumir binary logs do Hologres. Em comparação com o consumo de logs no modo JDBC, o consumo de logs no modo jdbc_fixed não ocupa conexões e não está sujeito a limites no número de walsenders. Para obter mais informações sobre o modo jdbc_fixed, consulte {{XREF_26}}.

V2.2 (Junho de 2024)

No Hologres V2.2 e posterior, a capacidade subjacente de coletar logs de consultas lentas é atualizada automaticamente para permitir que o Hologres registre mais informações sobre consultas lentas. Isso permite que a equipe de negócios realize um gerenciamento de granularidade fina com base no status das consultas executadas nas instâncias do Hologres. Para obter mais informações sobre logs de consultas lentas, consulte {{XREF_27}}. A coleta de logs de consultas lentas é atualizada nos seguintes aspectos:

• Consultas que falham devido a causas como sintaxe inválida, falhas de análise de plano e permissões insuficientes são registradas. Essas consultas não são registradas em versões anteriores ao Hologres V2.2. Recomendamos o uso do recurso {{XREF_28}} para gerenciar consultas com falha.

• Se uma transação contiver várias instruções de linguagem de definição de dados (DDL), como BEGIN; DROP TABLE xxx; COMMIT;, a transação inteira será registrada como um único registro de consulta nos logs de consultas lentas. No entanto, a métrica Query QPS conta a transação como várias instruções DDL. Exemplo:

  -- Initiate a query that contains multiple DDL statements in a transaction.
  BEGIN;
  DROP TABLE xxx;-- The execution succeeds.
  CREATE TABLE xxx -- The execution fails.
  ROLLBACK;

  • O código de exemplo a seguir mostra o resultado nos logs de consultas lentas:

    query_id | status  | Query
    ---------|---------|------------
    xxxx     |  FAILED |begin;drop table ;create table;rollback;

  • O código de exemplo a seguir mostra o resultado no sistema de monitoramento:

    Query QPS: 4 records
    Failed Query QPS: 1 record

V2.2 (Maio de 2024)

• No Hologres V2.2 e posterior, as propriedades da tabela retornadas por hg_dump_script são exibidas na sintaxe WITH em vez da sintaxe CALL. Isso ajuda a melhorar a conveniência e a legibilidade da instrução CREATE TABLE. Para obter mais informações, consulte a seção "Consultar um schema de tabela" em {{XREF_29}}.

• No Hologres V2.2.7 e posterior, o valor padrão é alterado de 1 segundo para 100 milissegundos. Após a alteração, os logs de consultas lentas registram instruções SQL que levam mais de 100 milissegundos em vez de 1 segundo. As instruções SQL incluem as instruções INSERT, SELECT, UPDATE e DELETE. Para obter mais informações, consulte {{XREF_30}}.

• No Hologres V2.2.9 e posterior, os resultados retornados por {{XREF_31}} não são ordenados com base na chave primária na cláusula WHERE.

  Exemplo de consultas pontuais usando fixed plans

  CREATE TABLE test_t (id INT PRIMARY key, col INT);
  INSERT INTO test_t VALUES (1,1),(2,2),(3,3);
  
  -- In versions earlier than Hologres V2.2.9, the returned results are ordered based on the primary key (id) in the WHERE clause. 
  SELECT * FROM test_t WHERE id IN (1,2,3);
  id | col 
  ----+----- 
  1 | 1 
  2 | 2 
  3 | 3
  
  -- In Hologres V2.2.9 and later, the returned results are not ordered based on the primary key (id) in the WHERE clause. Data in the result returned by each query may also be displayed in a different order. 
  SELECT * FROM test_t WHERE id IN (1,2,3);
  id | col 
  ----+----- 
  3 | 3 
  1 | 1 
  2 | 2

V2.2 (Abril de 2024)

• No Hologres V2.2 e posterior, o Hologres usa uma função vinculada ao serviço (service-linked role) por padrão para acessar tabelas externas do MaxCompute. Ao comprar ou atualizar para a V2.2 ou posterior, crie a função vinculada ao serviço e conceda a ela as permissões necessárias. As funções vinculadas ao serviço permitem o acesso autorizado entre serviços e evitam riscos de operações incorretas. Para obter mais informações, consulte {{XREF_32}}.

• No Hologres V2.2 e posterior, a política padrão do otimizador muda de exhaustive para exhaustive2, melhorando o desempenho em 20% a 40% na maioria dos casos. Para consultas left outer join, o plano pode ser subideal com maior uso de memória. Para reverter, execute set optimizer_join_order = 'exhaustive'; para voltar para exhaustive.

• No Hologres V2.2 e posterior, o valor de Engine Type para processos que usam fixed plans é alterado de SDK para FixedQE nos logs de consultas lentas. Isso garante a consistência de nomes nos logs e métricas de consultas lentas.

• No Hologres V2.2 e posterior, o número de conexões para um nó FE é aumentado de 128 para 256. O número total de conexões é dobrado. Para obter mais informações, consulte {{XREF_33}}.

• {{XREF_34}} e {{XREF_35}} agora estão disponíveis para uso geral (GA).

• No Hologres V2.2 e posterior, a instrução SELECT hg_dump_script() retorna as propriedades de criação de tabela com a sintaxe WITH em vez da sintaxe CALL. Essa alteração melhora a conveniência e a legibilidade da criação de tabelas. Para obter mais informações, consulte {{XREF_36}}.

V2.1 (Junho de 2024)

No Hologres V2.1.27 e posterior, se você usar o Realtime Compute for Apache Flink com VVR 8.0.7 ou posterior para consumir binary logs do Hologres, o modo JDBC será atualizado automaticamente para o modo jdbc_fixed. Em comparação com as consultas no modo JDBC, as consultas no modo jdbc_fixed não consomem conexões, e o desempenho da consulta não é limitado pelo número máximo de walsenders. Para obter mais informações sobre o modo jdbc_fixed, consulte {{XREF_37}}. Para obter mais informações sobre o modo JDBC, consulte {{XREF_38}}.

V2.1 (Março de 2024)

Ao usar o Realtime Compute for Apache Flink para consumir binary logs do Hologres, o modo HoloHub não é mais suportado, e a configuração 'sdkMode'='holohub' se torna inválida. Apenas o modo Java Database Connectivity (JDBC) é suportado. O modo JDBC é mais estável que o modo HoloHub e suporta mais tipos de dados. Antes de atualizar sua instância do Hologres para a V2.1, use uma das seguintes soluções para verificar a implantação do Realtime Compute for Apache Flink e sua instância do Hologres, garantindo que a implantação do Realtime Compute for Apache Flink possa ser executada conforme o esperado. Para obter mais informações, consulte {{XREF_39}}.

• Solução 1: Recomendada. Atualize a versão VVR do Realtime Compute for Apache Flink para 8.0.7 ou posterior e, em seguida, atualize sua instância do Hologres. Nesse caso, o Realtime Compute for Apache Flink altera automaticamente o modo HoloHub para o modo JDBC.

• Solução 2: Atualize a versão VVR do Realtime Compute for Apache Flink para uma versão entre 6.0.7 e 8.0.5, adicione a configuração 'sdkMode'='jdbc' para a tabela de origem do Realtime Compute for Apache Flink e reinicie a implantação. Conceda um dos seguintes conjuntos de permissões à conta de usuário usada para fazer login na instância do Hologres. Após confirmar que a implantação está funcionando corretamente, atualize sua instância do Hologres.

  • Permissões de superusuário na instância do Hologres

  • As permissões do proprietário da tabela, a permissão CREATE DATABASE e as permissões da função de replicação da instância do Hologres

• Solução 3: Não recomendada. Atualize a versão VVR do Realtime Compute for Apache Flink para 8.0.6 e, em seguida, atualize sua instância do Hologres. Nesse caso, o Realtime Compute for Apache Flink altera automaticamente o modo HoloHub para o modo JDBC. O Realtime Compute for Apache Flink que usa VVR 8.0.6 possui um defeito conhecido. Se as tabelas de dimensão contiverem um número excessivo de campos, as implantações do Realtime Compute for Apache Flink baseadas em VVR falharão devido a tempo limite (timeout). Para obter mais informações, consulte a seção "Hologres connector release note" em {{XREF_40}}.

• Opcional. Se você tiver um grande número de implantações do Realtime Compute for Apache Flink baseadas em VVR, poderá obter informações sobre as implantações e tabelas seguindo as instruções em {{XREF_41}}.

V2.1 (Fevereiro de 2024)

No Hologres V2.1.19, a multiplicação e a divisão de dados do tipo DECIMAL foram corrigidas. Nas versões anteriores à V2.1.19, um máximo de 18 casas decimais era suportado para operações básicas em dados do tipo DECIMAL. Se o resultado do cálculo tivesse mais de 18 casas decimais após a multiplicação ou divisão, os dados eram truncados antes do cálculo. Como resultado, o resultado do cálculo era inválido.

Por exemplo, a operação de multiplicação é realizada em dois valores decimais. O número total de dígitos antes e depois do ponto decimal (precision_ans) e o número de casas decimais (scale_ans) no resultado da multiplicação dos dois valores decimais são calculados usando as seguintes fórmulas:

precision_ans = precision_l + precision_r
scale_ans  = scale_l + scale_r

Se o valor de scale_ans for maior que 18, apenas 18 casas decimais são reservadas. Os valores decimais usados para multiplicação são truncados para o número especificado de casas decimais com base nas seguintes regras:

• Se scale_l ≤ 9, o valor decimal relacionado não é truncado, e o número de casas decimais para o valor decimal na operação de multiplicação é scale_l.

• Se scale_l > 9, o valor decimal relacionado é truncado para o número de casas decimais retornado por max(9,18-scale_r).

• Se scale_r ≤ 9, o valor decimal relacionado não é truncado, e o número de casas decimais para o valor decimal na operação de multiplicação é scale_r.

• Se scale_r > 9, o valor decimal relacionado é truncado para o número de casas decimais retornado por max(9,18-scale_l).

O código de exemplo a seguir fornece um exemplo:

CREATE TABLE t (a DECIMAL(30,10), b DECIMAL(30,10));
INSERT INTO t VALUES (1.1111111111, 1.0000000000),(1.1111111112, 1.0000000000);
SELECT a, b , a*b FROM t;

• Em versões anteriores à V2.1.19, se um multiplicador tivesse mais de 9 casas decimais válidas, ele era truncado para o número especificado de casas decimais, o que afetava negativamente a precisão. Como resultado, o resultado do cálculo era inválido.

  -- The calculation result in Hologres is invalid.
  1.1111111111, 1.0000000000,1.111111111000000000
  1.1111111112, 1.0000000000,1.111111111000000000
  
  -- The calculation result in PostgreSQL is valid.
  1.1111111111, 1.0000000000,1.111111111100000000
  1.1111111112, 1.0000000000,1.111111111200000000

• No Hologres V2.1.19 e posterior, esse problema foi corrigido. A operação de multiplicação é realizada nos valores decimais originais e, em seguida, o resultado da multiplicação é truncado para o número especificado de casas decimais. Isso garante alta precisão do resultado.

  -- The calculation result is valid.
  1.1111111111, 1.0000000000,1.111111111100000000
  1.1111111112, 1.0000000000,1.111111111200000000

V2.1 (Outubro de 2023)

Recursos específicos foram otimizados.

• No Hologres V2.1.12 e posterior, se você usar o recurso fixed plan para gravar dados em uma coluna do tipo DECIMAL, a precisão não for especificada e a precisão dos dados de origem for maior que a da coluna de destino, o Hologres arredondará os dados de origem com base na precisão da coluna de destino. No Hologres V2.1.11 e anterior, o Hologres trunca os dados de origem com base na precisão da coluna de destino. As instruções a seguir fornecem exemplos.

  Nota

  No Hologres V2.1.12 e posterior, o processo é o mesmo, independentemente de o recurso fixed plan ser usado ou não.

  CREATE TABLE fixed_plan_decimal (col DECIMAL(3,2));
  
  -- In Hologres V2.1.12 and later, the data 2.56 is written. In versions earlier than V2.1.12, the data 2.55 is written.
  INSERT INTO fixed_plan_decimal VALUES (2.555);
  
  -- In all Hologres versions, the data 2.55 is written.
  INSERT INTO fixed_plan_decimal VALUES (2.554);

• {{XREF_42}}, {{XREF_43}} e {{XREF_44}} concluíram a fase Beta e agora estão disponíveis para uso geral.

• Os requisitos de permissão para consumir Binlog do Hologres foram atualizados para exigir apenas permissão de leitura na tabela de destino. Para obter mais informações, consulte {{XREF_45}}.

• Se você usar o Bulkload para importar dados para uma tabela interna do Hologres que não possui chave de distribuição, o desempenho da importação pode piorar.

• No Hologres V2.1 e posterior, a sintaxe CREATE TABLE WITH PROPERTY é suportada para simplificar a configuração das propriedades da tabela. Para obter mais informações, consulte {{XREF_46}}.

• No Hologres V2.1 e posterior, a política de compactação para operações DELETE e UPDATE foi modificada para recuperar arquivos marcados prontamente. Isso pode reduzir o armazenamento e melhorar o desempenho de consultas para tabelas orientadas a colunas com operações DELETE/UPDATE frequentes. Após a atualização para a V2.1, a compactação em segundo plano de arquivos pequenos históricos consome muita CPU e pode levar mais de 10 minutos ou até várias horas, dependendo do volume de arquivos.

• No Hologres V2.1 e posterior, um mecanismo foi adicionado para verificar se todas as colunas especificadas em CONFLICT na sintaxe INSERT INTO <table_name> ON CONFLICT(<col_name>,...) DO são colunas de chave primária. Se alguma coluna não for uma coluna de chave primária, a execução da instrução SQL falhará. Para obter mais informações, consulte {{XREF_47}}.

• No Hologres V2.1 e posterior, a extensão dlf_fdw é criada por padrão para que você acesse data lakes usando tabelas externas. Você não precisa criar a extensão dlf_fdw manualmente. O parâmetro dlf_region não precisa ser especificado ao criar um servidor externo. Apenas os parâmetros dlf_endpoint, oss_endpoint e dlf_catalog precisam ser especificados. Uma verificação de formato foi adicionada para os parâmetros dlf_endpoint e oss_endpoint para evitar erros. Requisitos de formato:

  • dlf_endpoint: dlf-share.<nation>-<region>.aliyuncs.com

  • oss_endpoint:

    • OSS bucket: oss-<nation>-<region>-internal.aliyuncs.com

    • OSS-HDFS bucket: oss-<nation>-<region>.oss-dls.aliyuncs.com

• As seguintes palavras-chave são usadas como palavras-chave não reservadas: system_time, proctime e dynamic. Você não pode usar palavras-chave não reservadas como nomes de colunas em instruções SQL, podendo usá-las apenas como aliases. Você deve usar palavras-chave não reservadas após AS. Instruções de exemplo:

  -- In Hologres V2.0 and earlier, the three keywords can be used as column names or aliases in SQL statements.
  SELECT xxxx SYSTEM_TIME FROM t;
  
  SELECT xxxx AS SYSTEM_TIME FROM t;
  
  -- In Hologres V2.1 and later, the three keywords can only be used as aliases in SQL statements.
  SELECT xxxx AS SYSTEM_TIME FROM t;

V2.0 (Junho de 2023)

Recursos específicos foram otimizados.

• Ao usar o Realtime Compute for Apache Flink para consumir binary logs do Hologres, o modo JDBC é suportado. O modo HoloHub especificado pela configuração 'sdkMode'='holohub' será descontinuado em fases. O modo JDBC é mais estável que o modo HoloHub e suporta mais tipos de dados. Antes de atualizar sua instância do Hologres para a V2.0, use uma das seguintes soluções para verificar a implantação do Realtime Compute for Apache Flink e sua instância do Hologres, garantindo que a implantação do Realtime Compute for Apache Flink possa ser executada conforme o esperado. Para obter mais informações, consulte {{XREF_48}}.

  • Solução 1: Recomendada. Atualize a versão VVR do Realtime Compute for Apache Flink para 8.0.6 ou posterior e, em seguida, atualize sua instância do Hologres. Nesse caso, o Realtime Compute for Apache Flink altera automaticamente o modo HoloHub para o modo JDBC. O Realtime Compute for Apache Flink que usa VVR 8.0.6 possui um defeito conhecido. Se as tabelas de dimensão contiverem um número excessivo de campos, as implantações do Realtime Compute for Apache Flink baseadas em VVR falharão devido a tempo limite (timeout). Para obter mais informações, consulte a seção "Hologres connector release note" em {{XREF_49}}. Recomendamos atualizar a versão VVR do Realtime Compute for Apache Flink para 8.0.7.

  • Solução 2: Atualize a versão VVR do Realtime Compute for Apache Flink para 8.0.4 ou 8.0.5 e reinicie a implantação. Conceda um dos seguintes conjuntos de permissões à conta de usuário usada para fazer login na instância do Hologres. Após confirmar que a implantação está funcionando corretamente, atualize sua instância do Hologres.

    • Permissões de superusuário na instância do Hologres

    • As permissões do proprietário da tabela, a permissão CREATE DATABASE e as permissões da função de replicação da instância do Hologres

  • Solução 3: Atualize a versão VVR do Realtime Compute for Apache Flink para uma versão entre 6.0.7 e 8.0.3 e, em seguida, atualize sua instância do Hologres. Nesse caso, o Realtime Compute for Apache Flink ainda usa o modo HoloHub para consumir binary logs do Hologres.

• O modo de chamada de procedimento remoto (RPC) especificado pela configuração 'sdkMode'='rpc' ou 'rpcMode'='true' não é mais suportado por tabelas de dimensão e tabelas de resultados do Realtime Compute for Apache Flink. O modo JDBC é usado em seu lugar. Antes de atualizar sua instância do Hologres para a V2.0, execute as seguintes operações para verificar a implantação do Realtime Compute for Apache Flink e sua instância do Hologres, garantindo que a implantação do Realtime Compute for Apache Flink possa ser executada conforme o esperado. Para obter mais informações, consulte {{XREF_50}}.

  • Se a versão VVR do Realtime Compute for Apache Flink for 6.0.7 ou posterior, o sistema altera automaticamente o modo RPC para o modo JDBC. Nenhuma operação é necessária.

  • Se a versão VVR do Realtime Compute for Apache Flink for de 6.0.3 a 6.0.6, altere a configuração 'sdkMode'='rpc' para 'sdkMode'='jdbc' ou altere a configuração 'rpcMode'='true' para 'rpcMode'='false' nas implantações do Realtime Compute for Apache Flink.

  • Se a versão VVR do Realtime Compute for Apache Flink for 6.0.2 ou anterior, altere a configuração 'rpcMode'='true' para 'rpcMode'='false' nas implantações do Realtime Compute for Apache Flink.

  • Se as conexões com a sua instância do Hologres forem insuficientes, recomendamos configurar o parâmetro connectionPoolName para compartilhar conexões no pool de conexões. Você também pode atualizar a versão VVR do Realtime Compute for Apache Flink para 6.0.7 ou posterior e usar a configuração 'sdkMode'='jdbc_fixed'. Nesse caso, nenhuma conexão é ocupada.

  • O modo RPC não deduplica dados com a mesma chave primária no mesmo lote. O modo JDBC deduplica os dados automaticamente. Se você precisar reter dados completos em cenários de negócios, use a configuração 'jdbcWriteBatchSize'='1' para evitar a deduplicação.

• No Hologres V2.0 e posterior, você não pode usar o Blink para realizar consultas pontuais em tempo real sobre dados no Hologres ou gravar dados no Hologres. Recomendamos migrar suas implantações do Blink para o Realtime Compute for Apache Flink antes de atualizar sua instância do Hologres.

V2.0 (Abril de 2023)

Recursos específicos foram otimizados.

• No Hologres V2.0 e posterior, os dados no formato de segmento não podem ser armazenados no modo de armazenamento orientado a colunas. Instâncias do Hologres que contêm dados no formato de segmento não podem ser atualizadas para a V2.0 ou posterior. Você pode usar a função hg_convert_segment_orc para converter várias tabelas no formato de segmento em tabelas no formato Optimized Row Columnar (ORC) ao mesmo tempo. Para obter mais informações, {{XREF_51}}.

• Um limite superior é imposto ao número de shards para um grupo de tabelas ou uma instância. Isso ajuda a evitar o desperdício de recursos causado pelo uso indevido de grupos de tabelas. Para obter mais informações, consulte {{XREF_52}}.

• Os dados são gravados no DataHub no modo JDBC em vez do modo SDK. O modo JDBC é mais estável que o modo SDK e suporta mais tipos de dados.

• Por padrão, a extensão de binary log é configurada. Ao consumir dados de binary log no modo JDBC, você não precisa criar a extensão de binary log. Se você consumir dados de binary log no modo JDBC, o número máximo de walsenders que podem ser usados é aumentado em 10 vezes. Para uma instância configurada com 32 núcleos de CPU, o número máximo de walsenders é aumentado de 200 para 2.000. Os walsenders são contados como slots. Para obter mais informações, consulte {{XREF_53}}.

• Após atualizar sua instância do Hologres, o recurso auto-analyze é executado em tabelas para as quais nenhuma informação estatística foi coletada. Esse processo consome recursos de CPU e pode levar vários minutos ou até várias horas, dependendo do número de tabelas sem informações estatísticas coletadas.

• A previsão pública dos recursos de backup e restauração e de armazenamento em camadas foi concluída, e os recursos podem ser usados em ambientes de produção.

• A previsão pública do recurso de replicação no nível de compartilhamento foi concluída, e o recurso pode ser usado em ambientes de produção. Para obter mais informações, consulte {{XREF_54}}.

• Os parâmetros que especificam as propriedades da tabela foram padronizados. A sintaxe usada para configurar as propriedades da tabela quando os nomes das colunas contêm letras maiúsculas foi alterada. Para obter mais informações, consulte {{XREF_55}}. O valor auto não é suportado para a propriedade bitmap_columns. Essa alteração não afeta o uso das tabelas existentes.

• A função HG_CREATE_TABLE_LIKE pode herdar índices criados, colunas do tipo de dados SERIAL e colunas para as quais índices de vetor proxima foram criados.

V1.3 (Junho de 2023)

• No Hologres V1.3.53 e posterior, a contagem de réplicas deve ser menor ou igual ao número de workers. Para obter mais informações, consulte {{XREF_56}}.

• O resultado de cálculo da função Avg foi otimizado. Nas versões do Hologres anteriores à V1.3, a função Avg retornava o resultado do cálculo com no máximo seis casas decimais. Se o resultado do cálculo contivesse mais de seis casas decimais, ele era truncado. No Hologres V1.3 e posterior, a função Avg retorna o resultado do cálculo com casas decimais completas.

• O valor do tipo TEXT convertido a partir de um valor do tipo DECIMAL foi otimizado. Nas versões do Hologres anteriores à V1.3.46, o valor do tipo TEXT convertido a partir de um valor do tipo DECIMAL era exibido em formato de notação científica. No Hologres V1.3.46 e posterior, o valor do tipo TEXT convertido a partir de um valor do tipo DECIMAL é exibido diretamente. Instruções SQL de exemplo:

  CREATE TABLE t (a INT, b DECIMAL(38,10));
  INSERT INTO t VALUES (1,1);
  INSERT INTO t VALUES (1,0);
  SELECT a,b,b::text FROM t;
  -- In Hologres V1.3.46 or later, the following result is returned:
  a	|  b	        |b
  --+-------------+------
  1 |0.0000000000	|0.0000000000
  1 |1.0000000000	|1.0000000000
  
  -- In versions earlier than Hologres V1.3.46, the following result is returned:
  a	|  b	        |b
  --+-------------+------
  1 |0.0000000000	|0.E-10
  1 |1.0000000000	|1.0000000000

Alterações de comportamento padrão no Hologres V1.3 lançado em fevereiro de 2023

Recursos específicos foram otimizados.

No Hologres V1.3.36 e posterior, você pode criar uma view entre schemas usando o modelo de permissão no nível de schema (SLPM). Para obter mais informações, consulte {{XREF_57}}.

V1.3 (Janeiro de 2023)

Recursos específicos foram otimizados.

• No Hologres V2.0 e posterior, tabelas no formato de segmento não são mais suportadas. No Hologres V1.3.35 e posterior, uma instrução é fornecida para converter várias tabelas no formato de segmento em tabelas no formato ORC ao mesmo tempo. Essa conversão facilita a migração de dados nas tabelas existentes. Para obter mais informações, consulte {{XREF_58}}. Instâncias do Hologres que contêm dados no formato de segmento não podem ser atualizadas para uma versão posterior.

• No Hologres V1.3.35 e posterior, mais parâmetros Grand Unified Configuration (GUC) para o recurso fixed plan são definidos como on por padrão. Isso melhora a usabilidade e o desempenho do sistema. Para obter mais informações, consulte {{XREF_59}}.

V1.3 (Dezembro de 2022)

Recursos específicos foram otimizados.

• A partir de December 26, 2022, a Alibaba Cloud não fornece mais endpoints de virtual private cloud (VPC) para novas instâncias, incluindo as instâncias criadas usando o recurso de backup ou restauração. Você pode especificar endpoints VPC que são mais seguros. O endpoint VPC que você especificar será conectado apenas à VPC selecionada ao comprar uma instância do Hologres. Isso proporciona melhor segurança e isolamento. As instâncias existentes não são afetadas. Recomendamos desativar o endpoint VPC original e especificar um endpoint VPC em seu lugar.

• No Hologres V1.3.31 e posterior, você pode criptografar dados no Hologres e consultar dados criptografados do MaxCompute por padrão. Você não precisa mais configurar definições adicionais nem abrir um ticket. Para obter mais informações, consulte {{XREF_60}} e {{XREF_61}}.

V1.3 (Novembro de 2022)

V1.3 (Outubro de 2022)

V1.3 (Setembro de 2022)

V1.3 (Julho de 2022)

V1.1 (Julho de 2022)

V1.1 (Abril de 2022)

O uso de memória foi otimizado.

No Hologres V1.1.53 e posterior, o uso de memória é otimizado e as métricas de O&M de backend são relatadas de forma mais eficiente, liberando mais memória para computação. Atualize para a V1.1.53 com base nos requisitos do seu negócio.

V1.1 (Março de 2022)

O desempenho de consultas pontuais iniciadas usando fixed plans foi otimizado.

No Hologres V1.1.49 e posterior, o desempenho de consultas pontuais iniciadas usando fixed plans é otimizado. Em consultas pontuais que envolvem uma grande quantidade de dados, o throughput é melhorado em mais de 30%. Você pode atualizar a versão da sua instância do Hologres para V1.1.49 ou posterior com base nos requisitos do seu negócio. Para obter mais informações sobre fixed plans, consulte {{XREF_78}}.

V1.1 (Março de 2022)

As propriedades são verificadas quando uma tabela filha é anexada a uma tabela pai.

No Hologres V1.1.42 e posterior, as propriedades de uma tabela filha e de uma tabela pai são estritamente verificadas após você iniciar uma solicitação para anexar a tabela filha à tabela pai. Se uma propriedade da tabela filha não for consistente com a da tabela pai, um erro será relatado e a operação de anexação falhará. As propriedades que o sistema verifica incluem chaves primárias, índices e a restrição NOT NULL. Antes de criar uma tabela filha, certifique-se de que as propriedades da tabela filha sejam consistentes com as da tabela pai. Para obter mais informações, consulte {{XREF_79}}.

-- In this example, the following data definition language (DDL) statements are executed to create a parent table and a child table.
BEGIN;
CREATE TABLE public.hologres_parent(
  a INT,
  b text NOT NULL,
  c timestamptz NOT NULL,
  ds text,
  PRIMARY KEY(a,ds)
)
 PARTITION BY LIST(ds);
CALL set_table_property('public.hologres_parent', 'orientation', 'column');
CALL set_table_property('public.hologres_parent', 'distribution_key', 'a');
CALL set_table_property('public.hologres_parent', 'clustering_key', 'b');
CALL set_table_property('public.hologres_parent', 'event_time_column', 'c');

CREATE TABLE public.hologres_child PARTITION OF public.hologres_parent 
FOR VALUES IN('20201103');

COMMIT;

-- Create a temporary child partitioned table.
BEGIN;
CREATE TABLE IF NOT EXISTS public.tmp_hologres_child(
  a INT,
  b text NOT NULL,
  c timestamptz NOT NULL,
  ds text,
  PRIMARY KEY (a,ds)
);
CALL set_table_property('public.tmp_hologres_child', 'orientation', 'column');
CALL set_table_property('public.tmp_hologres_child', 'distribution_key', 'a');
CALL set_table_property('public.tmp_hologres_child', 'clustering_key', 'a,b');
CALL set_table_property('public.tmp_hologres_child', 'event_time_column', 'c');
COMMIT;

-- Import data from a foreign table to the temporary child partitioned table.
INSERT INTO public.tmp_hologres_child SELECT * FROM foreign_table WHERE ds='20201103';

-- Drop the original child partitioned table and associate the temporary child partitioned table with the parent table.
BEGIN;
DROP TABLE IF EXISTS  public.hologres_child;
ALTER TABLE public.tmp_hologres_child RENAME TO hologres_child;
ALTER TABLE public.hologres_parent ATTACH PARTITION public.hologres_child
FOR VALUES IN ('20201103');
COMMIT ;

-- Error cause.
ERROR: 
partition index hologres_child's immutable properties(e.g. clustering_key, event_time_column) is consistent with parent.  
Hint: create partition with [create table ... partition of ...] to be consistent with parent.                

V1.1 (Dezembro de 2021)

Por padrão, o endpoint público de uma nova instância do Hologres é desativado.

Para atender aos requisitos de segurança para controle de acesso a dados, os endpoints públicos de novas instâncias do Hologres são desativados automaticamente e os recursos de acesso à Internet não são fornecidos por padrão a partir das 00:00:00 de 7 de dezembro de 2021. Se você quiser se conectar à sua instância do Hologres usando um endpoint público, poderá ativar o endpoint público no console do Hologres.

V1.1 (Novembro de 2021)

A memória máxima usada para computação não é mais limitada a 20 GB por nó.

V1.1 (Outubro de 2021)

• Por padrão, o recurso auto-analyze está ativado.

  O auto-analyze, introduzido na V0.10 e comprovado em produção, é ativado por padrão para novas instâncias na V1.1. Instâncias atualizadas mantêm sua configuração existente. O nome do parâmetro também foi alterado na V1.1:

  Nome original do parâmetro	Novo nome do parâmetro	Valor padrão
  hg_experimental_enable_start_auto_analyze_worker	hg_enable_start_auto_analyze_worker	on

  Para obter mais informações sobre como usar o recurso auto-analyze, consulte {{XREF_80}}.

• O nome de uma função relacionada a um grupo de tabelas foi alterado.

  O recurso de resharding, introduzido na V0.10 e comprovado em produção, teve sua função de grupo de tabelas renomeada na V1.1:

  Nome original da função	Novo nome da função
  hg_update_table_shard_count('table_name','table_group_name')	hg_move_table_to_table_group('table_name','table_group_name')

  • Para obter mais informações sobre como usar o recurso de resharding, consulte {{XREF_81}}.

  • Para obter mais informações sobre como usar grupos de tabelas, consulte {{XREF_82}}.

• O mecanismo para acesso acelerado a tabelas externas do MaxCompute no Hologres foi alterado.

  Um novo mecanismo de tabela externa do MaxCompute, introduzido na V0.10, melhora o desempenho em mais de 30%. Na V1.1, esse mecanismo é o padrão para novas instâncias; instâncias atualizadas mantêm seu mecanismo existente. Os nomes dos parâmetros também foram alterados:

  Nome original do parâmetro	Novo nome do parâmetro	Observações
  hg_experimental_enable_access_odps_orc_via_holo	hg_enable_access_odps_orc_via_holo	Valor padrão: on.
  hg_experimental_foreign_table_executor_max_dop	hg_foreign_table_executor_max_dop	O valor padrão foi alterado para o número de núcleos de CPU de uma instância. O valor máximo é 128.
  Nenhum	hg_foreign_table_executor_dml_max_dop	Este parâmetro foi adicionado no Hologres V1.1. O valor padrão é 32. Este parâmetro aplica-se a instruções DML relacionadas a tabelas externas.
  hg_experimental_foreign_table_split_size	hg_foreign_table_split_size	Valor padrão: 64. Unidade: MB.
  hg_experimental_foreign_table_max_partition_limit	hg_foreign_table_max_partition_limit	O valor padrão é 512. O valor indica que até 512 partições podem ser verificadas para uma consulta.
  hg_experimental_enable_write_maxcompute	Nenhum	No Hologres V1.1, o valor padrão é on. O valor on indica que os dados podem ser gravados de volta no MaxCompute. Para obter mais informações, consulte {{XREF_83}}.

  Para obter mais informações sobre os parâmetros, consulte {{XREF_84}}.

• A tabela pg_stat_activity registra o status das conexões ativas para todos os nós frontend.

  Nas versões anteriores à V1.1, pg_stat_activity registrava conexões ativas apenas para um único nó FE. Na V1.1, ela abrange todos os nós FE. Para obter mais informações sobre como gerenciar consultas ativas usando a tabela pg_stat_activity, consulte {{XREF_85}}.

• O mecanismo de gerenciamento de conexões foi ajustado.

  No Hologres V1.1 e posterior, as conexões são reservadas para o superusuário, e a lógica do pool de conexões do HoloWeb é otimizada. O superusuário pode usar o HoloWeb para gerenciar ou liberar conexões quando o limite de conexões for excedido. Para obter mais informações, consulte {{XREF_86}}.

• O valor padrão do parâmetro idle_in_transaction_session_timeout foi alterado.

  O parâmetro idle_in_transaction_session_timeout especifica o tempo limite para transações ociosas. Sem essa configuração, as transações que atingem o tempo limite não são revertidas, arriscando deadlocks. Na V1.1, idle_in_transaction_session_timeout tem como padrão 10 minutos. Para obter mais informações, consulte {{XREF_87}}.