Hologres:Alterações de comportamento padrão

V4.2

V4.1

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

V4.0 (Setembro de 2025)

V3.2 (Julho de 2025)

• Adição de palavras-chave não reservadas como Branch, Overwrite, Parameter e Tag; adição de palavras-chave reservadas como Lambda e Qualify. Para informações sobre palavras-chave, consulte Palavras-chave do PostgreSQL.

• A partir do Hologres V3.2, há suporte para otimização adaptativa de CTEs. 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 deixam de ser embutidas forçosamente. 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çosamente.

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

• A partir do Hologres V3.2, o Fast Rows está habilitado 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 detalhes, consulte: ANALYZE e AUTO ANALYZE.

V3.1 (Maio de 2025)

• Dynamic tables:

  • Sintaxe

    A partir do Hologres V3.1, as dynamic tables utilizam uma nova sintaxe mais concisa. Após a atualização de dynamic tables 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, deve-se usar a nova sintaxe da V3.1. Para tabelas que usam atualização incremental de dados, é necessário recriar a tabela usando a nova sintaxe. Para mais informações, consulte Criar dynamic table.

  • Uso de recursos

    • Recursos de atualização

      As dynamic tables 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 habilitada, ela retornará automaticamente aos recursos da instância. Tabelas criadas no Hologres V3.0 continuam a usar os recursos especificados no momento da criação da tabela. Para mais informações, consulte Criar dynamic table.

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

      • Nova sintaxe (Hologres V3.1 e V3.2): Utilizam-se as virtual warehouses primárias dos grupos de tabelas da tabela base e da dynamic table.

      • Sintaxe antiga (Hologres V3.0) e nova sintaxe (Hologres V4.1): Utiliza-se a virtual warehouse primária do grupo de tabelas da dynamic table.

  • Contagem de conexões

    A nova sintaxe mantém uma conexão adicional por dynamic table. Se sua instância tiver alta utilização de conexões e centenas de dynamic tables, remova conexões ociosas para evitar problemas.

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

    A partir do Hologres V3.1 e posteriores, o método stream é usado para identificar alterações de dados na tabela base. Comparado ao binary logging, o método stream oferece maior desempenho e é mais econômico. Após a atualização da instância para a V3.1, o método stream é usado por padrão. Se o binary logging estiver habilitado para sua tabela na V3.0, desative-o prontamente para evitar custos extras de armazenamento. Para mais informações, consulte Dynamic tables.

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

  • TRUNCATE agora é uma instrução DML (antes era DDL), reduzindo a pressão nos nós FE. Para reverter ao 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 habilitado, você precisa desativar o binary logging no nível de sessão. Para mais informações, consulte TRUNCATE.

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

  • 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á reportada. Para mais informações, consulte INSERT OVERWRITE.

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

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

  V3.0

  Abril de 2025

  A partir do Hologres V3.0.33, o limite superior de recursos de computação serverless disponíveis para uma instância aumentou de 3 vezes os recursos de computação exclusiva da instância para 5 vezes. O limite superior não pode exceder 2.048 CUs. Para mais informações, consulte Trabalhar com computação serverless.

  Fevereiro de 2025

  • A partir do Hologres V3.0.23, usuários sem as permissões necessárias não podem consultar metadados de banco de dados, esquemas ou tabelas. O acesso não autorizado via BI ou outras ferramentas retorna um erro de permissão.

  • A partir do Hologres V3.0, instruções SQL que contêm LIMIT -1 não são suportadas. Se você executar uma instrução SQL contendo LIMIT -1, o erro ERROR: LIMIT must not be negative será reportado.

  • A partir do Hologres V3.0.19, para aumentar a segurança dos dados, logs binários não podem ser consumidos por padrão em bancos de dados com mascaramento de dados habilitado. A mensagem de erro Replication does not support hologres anon now, could choose to turn off hg_anon_enable for current user será reportada ao tentar consumir logs binários. Para permitir que um usuário consuma logs binários, execute uma das seguintes instruções para desativar o mascaramento de dados para esse usuário.

    Importante

    O sistema verifica se o consumo de logs binários é permitido baseando-se apenas na configuração de hg_anon_enable. Não é possível habilitar o consumo de logs binários configurando uma regra de mascaramento de dados como unmasked.

    -- Disable data masking for a user.
    ALTER ROLE "<user>" SET hg_anon_enable = OFF;
    
    -- Disable data masking in a specific database for a user.
    ALTER ROLE "<user>" IN DATABASE <database> SET hg_anon_enable = OFF;

  Novembro de 2024

  O limite superior para o número de combinações de condições de filtro em um fixed plan é 500.000. Se esse limite for excedido, a execução sofrerá degradação para o Hologres Query Engine (HQE). Descrições dos valores nas condições de filtro:

  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.

  Setembro de 2024

  • A prévia pública do recurso SQL Hint foi concluída, e o recurso pode ser usado em ambientes de produção. Por padrão, este recurso está habilitado.

  • Em data warehouses de metadados, dois registros são gerados para uma operação COPY em vez de um único registro. Para mais informações, consulte COPY.

  • No Hologres V3.0.10 e posterior, o número máximo de unidades de computação (CUs) para cada virtual warehouse em uma instância de virtual warehouse aumenta de 512 para 1024.

  V2.2

  Fevereiro de 2025

  • A partir do Hologres V2.2.38, para aumentar a segurança dos dados, logs binários não podem ser consumidos por padrão em bancos de dados com mascaramento de dados habilitado. A mensagem de erro Replication does not support hologres anon now, could choose to turn off hg_anon_enable for current user será reportada ao tentar consumir logs binários. Para permitir que um usuário consuma logs binários, execute uma das seguintes instruções para desativar o mascaramento de dados para esse usuário.

    Importante

    O sistema verifica se o consumo de logs binários é permitido baseando-se apenas na configuração de hg_anon_enable. Não é possível habilitar o consumo de logs binários configurando uma regra de mascaramento de dados como unmasked.

    -- Disable data masking for a user.
    ALTER ROLE "<user>" SET hg_anon_enable = OFF;
    
    -- Disable data masking in a specific database for a user.
    ALTER ROLE "<user>" IN DATABASE <database> SET hg_anon_enable = OFF;

  Novembro de 2024

  • No Hologres V2.2.17 e posterior, a memória do plano de execução tem um limite de 4 GB (padrão) para reduzir o risco de OOM. Se ocorrer o erro "ORCA failed to produce a plan : Used memory size xxx MB exceeds maximum size 4096 MB", simplifique a instrução SQL ou ajuste o limite:

    -- Adjust or cancel the limit. If you set the parameter to 0, the limit is canceled.
    ALTER DATABASE <database_name> SET hg_experimental_mp_allocated_size_limit_in_mb = 0;

  • No Hologres V2.2.25 e posterior, ao reduzir horizontalmente uma virtual warehouse, o número de shards somente leitura alocados para cada worker não pode exceder 128. Isso evita ocorrências frequentes de problemas como OOM. Se o número de shards alocados para um worker exceder 128 após a redução, o erro "The follower shard count per worker:xx should be less than or equal to the max follower shard" será reportado. Nesse caso, as especificações originais são mantidas para a virtual warehouse. Você pode executar a seguinte instrução SQL para consultar o número de shards somente leitura alocados aos workers em uma virtual warehouse específica no banco de dados atual. Se a instância tiver vários bancos de dados, some os números de shards somente leitura em todos os bancos.

    -- Query the number of read-only shards allocated to workers of init_warehouse in the current database.
    SELECT
        w.worker_id,
        count(*) AS cnt
    FROM
        hologres.hg_warehouse_table_groups t,
        hologres.hg_worker_info w
    WHERE
        t.warehouse_id = w.warehouse_id
        AND w.table_group_name = t.tablegroup_name
        AND t.leader = FALSE
        AND w.warehouse_name = 'init_warehouse'
    GROUP BY
        w.worker_id;

  V2.2 (Julho de 2024)

  Ao usar Java Database Connectivity (JDBC) para consumir logs binários do Hologres, o número máximo de walsenders disponíveis para um worker diminuiu de 1.000 para 600. O número de walsenders é calculado pelo número de slots. Para mais informações, consulte Consumir Binlog via JDBC. Recomendamos o uso do modo jdbc_fixed para consumir logs binários do Hologres. Comparado ao consumo de logs no modo JDBC, o consumo no modo jdbc_fixed não ocupa conexões e não está sujeito a limites no número de walsenders. Para mais informações sobre o modo jdbc_fixed, consulte Hologres: Data warehouse em tempo real.

  V2.2 (Junho de 2024)

  No Hologres V2.2 e posterior, a capacidade subjacente de coleta de logs de consultas lentas é atualizada automaticamente para permitir que o Hologres registre mais informações sobre consultas lentas. Isso permite que as equipes realizem gerenciamento refinado com base no status das consultas executadas nas instâncias do Hologres. Para mais informações sobre logs de consultas lentas, consulte Obter e analisar logs de consultas lentas. A coleta de logs de consultas lentas foi aprimorada nos seguintes aspectos:

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

  • Se uma transação contiver múltiplas instruções de linguagem de definição de dados (DDL), como BEGIN; DROP TABLE xxx; COMMIT;, toda a transação é registrada como um único registro de consulta nos logs de consultas lentas. No entanto, a métrica Query QPS conta a transação como múltiplas 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 de 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 mais informações, veja a seção "Consultar esquema de tabela" em Visão geral.

  • No Hologres V2.2.7 e posterior, o valor padrão mudou 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 INSERT, SELECT, UPDATE e DELETE. Para mais informações, consulte Obter e analisar logs de consultas lentas.

  • No Hologres V2.2.9 e posterior, os resultados retornados por consultas pontuais de pares chave-valor usando fixed plans 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 a serviço por padrão para acessar tabelas externas do MaxCompute. Ao comprar ou atualizar para a V2.2 ou posterior, crie a função vinculada a serviço e conceda a ela as permissões necessárias. Funções vinculadas a serviço permitem acesso autorizado entre serviços e previnem riscos de operações incorretas. Para mais informações, consulte Função vinculada a serviço para Hologres.

  • No Hologres V2.2 e posterior, a política padrão do otimizador muda de exhaustive para exhaustive2, melhorando o desempenho em 20%–40% na maioria dos casos. Para consultas left outer join, o plano pode ser subótimo 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 mudou de SDK para FixedQE nos logs de consultas lentas. Isso garante consistência de nomes nos logs de consultas lentas e nas métricas.

  • No Hologres V2.2 e posterior, o número de conexões para um nó FE aumentou de 128 para 256. O número total de conexões dobrou. Para mais informações, consulte Gerenciamento de instâncias.

  • INSERT OVERWRITE e Funções BSI agora estão disponíveis geralmente.

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

  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 logs binários do Hologres, o modo JDBC é atualizado automaticamente para o modo jdbc_fixed. Comparado às 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 mais informações sobre o modo jdbc_fixed, consulte Hologres: Data warehouse em tempo real. Para mais informações sobre o modo JDBC, consulte Consumir Binlog via JDBC.

  V2.1 (Março de 2024)

  Ao usar o Realtime Compute for Apache Flink para consumir logs binários do Hologres, o modo HoloHub não é mais suportado, e a configuração 'sdkMode'='holohub' torna-se 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 possa funcionar conforme esperado. Para mais informações, consulte Consumir Binlog via JDBC.

  • 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

    • Permissões de proprietário da tabela, permissão CREATE DATABASE e 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 de rascunho do Realtime Compute for Apache Flink baseado em VVR falharão devido a tempo limite. Para mais informações, consulte a seção "Nota de lançamento do conector Hologres" em Visão geral.

  • 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 Usar Realtime Compute for Apache Flink ou Blink para consumir logs binários do Hologres em tempo real.

  V2.1 (Fevereiro de 2024)

  No Hologres V2.1.19, a multiplicação e divisão de dados do tipo DECIMAL foram corrigidas. Em versões anteriores à V2.1.19, eram suportadas no máximo 18 casas decimais 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, ao realizar a operação de multiplicação 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 preservadas. 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 superior à da coluna de destino, o Hologres arredonda os dados de origem com base na precisão da coluna de destino. No Hologres V2.1.11 e anteriores, 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);

  • Mapa de dados, linhagem de dados e Criptografia de Transmissão concluíram a fase Beta e agora estão disponíveis geralmente.

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

  • Se você usar 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 de propriedades de tabela. Para mais informações, consulte CREATE TABLE.

  • 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 frequentes de DELETE/UPDATE. Após atualizar para a V2.1, a compactação em segundo plano de arquivos pequenos históricos consome CPU significativa e pode levar mais de 10 minutos ou até várias horas, dependendo do volume de arquivos.

  • No Hologres V2.1 e posterior, foi adicionado um mecanismo 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 de chave primária, a execução da instrução SQL falhará. Para mais informações, consulte INSERT ON CONFLICT (UPSERT).

  • No Hologres V2.1 e posterior, a extensão dlf_fdw é criada por padrão para que você possa acessar data lakes usando tabelas externas. Não é necessário criar manualmente a extensão dlf_fdw. 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:

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

      • Bucket OSS-HDFS: 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 alias. É obrigatório 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 logs binários 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 possa funcionar conforme esperado. Para mais informações, consulte Consumir Binlog via JDBC.

    • 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 de rascunho do Realtime Compute for Apache Flink baseado em VVR falharão devido a tempo limite. Para mais informações, consulte a seção "Nota de lançamento do conector Hologres" em Visão geral. 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

      • Permissões de proprietário da tabela, permissão CREATE DATABASE e 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 logs binários 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 resultado 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 possa funcionar conforme esperado. Para mais informações, consulte Hologres: Data warehouse em tempo real.

    • 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 à 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 em 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, dados no formato segment não podem ser armazenados no modo de armazenamento orientado a colunas. Instâncias do Hologres que contêm dados no formato segment não podem ser atualizadas para a V2.0 ou posterior. Você pode usar a função hg_convert_segment_orc para converter múltiplas tabelas no formato segment em tabelas no formato Optimized Row Columnar (ORC) simultaneamente. Para mais informações, Atualizar formato de armazenamento de tabela orientada a colunas.

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

  • 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 log binário é configurada. Ao consumir dados de log binário no modo JDBC, você não precisa criar a extensão de log binário. Se você consumir dados de log binário no modo JDBC, o número máximo de walsenders que podem ser usados aumenta 10 vezes. Para uma instância configurada com 32 núcleos de CPU, o número máximo de walsenders aumenta de 200 para 2.000. Walsenders são contados como slots. Para mais informações, consulte Consumir Binlog via JDBC.

  • 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 prévia pública do recurso de backup e restauração e do recurso de armazenamento em camadas foi concluída, e os recursos podem ser usados em ambientes de produção.

  • A prévia pública do recurso de replicação no nível de shard foi concluída, e o recurso pode ser usado em ambientes de produção. Para mais informações, consulte Replicação no nível de shard para alto throughput.

  • Os parâmetros que especificam propriedades de tabela foram padronizados. A sintaxe usada para configurar propriedades de tabela se os nomes das colunas contiverem letras maiúsculas mudou. Para mais informações, consulte CREATE TABLE. O valor auto não é suportado para a propriedade bitmap_columns. Essa alteração não afeta o uso de 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 vetoriais 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 mais informações, consulte Replicação no nível de shard para alto throughput (Beta).

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

  • O valor do tipo TEXT convertido a partir de um valor do tipo DECIMAL foi otimizado. Em 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 visão entre esquemas usando o modelo de permissão no nível de esquema (SLPM). Para mais informações, consulte Usar o SLPM.

  V1.3 (Janeiro de 2023)

  Recursos específicos foram otimizados.

  • No Hologres V2.0 e posterior, tabelas no formato segment não são mais suportadas. No Hologres V1.3.35 e posterior, uma instrução é fornecida para converter múltiplas tabelas no formato segment em tabelas no formato ORC simultaneamente. Essa conversão facilita a migração de dados em tabelas existentes. Para mais informações, consulte Atualizar formato de armazenamento de tabela orientada a colunas. Instâncias do Hologres que contêm dados no formato segment 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 mais informações, consulte Acelerar execução SQL com fixed plans.

  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 instâncias criadas usando o recurso de backup ou restauração. Você pode especificar endpoints VPC que são mais seguros. O endpoint VPC especificado conecta-se apenas à VPC selecionada ao comprar uma instância do Hologres. Isso proporciona melhor segurança e isolamento. 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. Não é mais necessário configurar definições adicionais ou abrir um ticket. Para mais informações, consulte Criptografar dados em repouso e Consultar dados criptografados do MaxCompute.

  V1.3 (Novembro de 2022)

  Recursos específicos foram otimizados.

  • No Hologres V1.3.28 e posterior, dados em colunas configuradas como clustering key ou segment key não podem conter null values. Para mais informações, consulte Clustering key e Coluna de tempo de evento (segment key).

  • No Hologres V1.3.28 e posterior, o valor padrão do parâmetro hg_experimental_load_all_foreign_table_interval_time mudou de 5min para 30min. Esse parâmetro especifica o intervalo no qual inspeções são realizadas periodicamente para criar automaticamente tabelas externas para todas as tabelas do MaxCompute. Para mais informações, consulte Criar automaticamente tabelas externas para tabelas do MaxCompute.

  • No Hologres V1.3.28 e posterior, colunas configuradas como chave de distribuição não podem conter strings vazias. Para mais informações, consulte Chave de distribuição.

  • No Hologres V1.3.27 e posterior, o limiar de latência de sincronização de dados da instância primária para uma instância secundária mudou de 20 minutos para 60 minutos. Se a latência de sincronização exceder 60 minutos, a instância secundária é reiniciada automaticamente. Para mais informações, consulte Configurar implantação de alta disponibilidade com múltiplas instâncias.

  V1.3 (Outubro de 2022)

  Recursos específicos foram otimizados.

  • No Hologres V1.3.24 e posterior, você pode usar a visualização de sistema hg_worker_info para consultar relações de alocação entre shards e nós worker. Isso ajuda a resolver o problema de alocação desigual de recursos de computação. Para mais informações, consulte Detectar e lidar com desequilíbrio de carga.

  • No Hologres V1.3.24 e posterior, o tempo de vida (TTL) mínimo de dados de tabela é de um dia (86.400 segundos). Para mais informações, consulte Outras instruções PostgreSQL.

  • No Hologres V1.3.24 e posterior, se você habilitar binary logging para o Hologres, a função pg_relation_size retorna o tamanho dos logs binários. Para mais informações, consulte Consultar tamanhos de armazenamento de tabelas e bancos de dados.

  • No Hologres V1.3.24 e posterior, você pode configurar o TTL de logs binários para tabelas filhas com base nos requisitos do seu negócio. Para mais informações, consulte Assinar binlogs do Hologres.

  V1.3 (Setembro de 2022)

  Recursos específicos foram otimizados.

  • Se o TTL expirar e a mesma chave primária for compartilhada, a gravação de dados falhará. No Hologres V1.3.23 e posterior, você pode usar uma instrução SQL para corrigir esse problema. Para mais informações, consulte INSERT ON CONFLICT (UPSERT).

  • No Hologres V1.3.22 e posterior, você pode unir tabelas de sistema do PostgreSQL com tabelas internas do Hologres que você criou. Você também pode exportar dados de tabelas de sistema do PostgreSQL para tabelas internas do Hologres. Para mais informações, consulte Tabelas de sistema.

  • No Hologres V1.3.22 e posterior, colunas do tipo DATE podem ser configuradas como colunas de chave primária ou colunas de chave de partição. Para mais informações, consulte CREATE TABLE.

  • No Hologres V1.3.21 e posterior, você pode usar a instrução Create Table As para criar uma tabela que tenha a mesma estrutura e dados de uma tabela existente. Para mais informações, consulte CREATE TABLE AS.

  V1.3 (Julho de 2022)

  Recursos específicos foram otimizados.

  • A prévia pública de recursos relacionados a JSON foi concluída. Os recursos foram lançados oficialmente.

  • A prévia pública de recursos relacionados ao PostGIS foi concluída. Os recursos foram lançados oficialmente.

  • Ao inserir dados usando um método como Data Integration ou Realtime Compute for Apache Flink, recomendamos usar instruções SQL em vez de SDKs para gravar dados. As instruções SQL são instruções INSERT.

  V1.1 (Julho de 2022)

  Várias métricas foram adicionadas ao Hologres para melhorar suas capacidades de autodiagnóstico e auto-O&M. As métricas ajudam a identificar problemas e consultar detalhes de uso de recursos de maneira mais precisa. Isso melhora a disponibilidade geral do Hologres. Ao usar as métricas, observe os seguintes itens:

  • As métricas adicionadas em julho de 2022 aplicam-se apenas ao Hologres V1.1 e posterior. Se a versão da sua instância do Hologres for anterior à V1.1, atualize manualmente sua instância do Hologres no console do Hologres ou entre no grupo do DingTalk para suporte técnico. Para mais informações sobre como atualizar manualmente sua instância do Hologres no console do Hologres, consulte Atualização manual (beta). Para mais informações sobre como obter suporte técnico, consulte Obter suporte online para Hologres.

  • As métricas de CPU e memória agora são calculadas com mais precisão. Após a atualização de julho de 2022, a utilização de CPU e o uso de memória de instâncias V1.1 podem flutuar entre 5% e 10%, inclusive no CloudMonitor. Reconfigure os limiares de monitoramento adequadamente.

  Para mais informações sobre as métricas, consulte Métricas de monitoramento.

  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 mais informações sobre fixed plans, consulte Acelerar execução SQL com fixed plans.

  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 rigorosamente 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 é reportado e a operação de anexação falha. 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 mais informações, consulte CREATE PARTITION TABLE.

  O código de exemplo a seguir fornece um cenário de exemplo no qual a clustering key da tabela filha é inconsistente com a da tabela pai. Nesse caso, a tabela filha falha ao ser anexada à tabela pai.

  -- 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 as capacidades de acesso à Internet não são fornecidas por padrão a partir das 00:00:00 de 7 de dezembro de 2021. Se desejar conectar-se à sua instância do Hologres usando um endpoint público, você pode habilitar o endpoint público no console do Hologres.

  V1.1 (Novembro de 2021)

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

  No Hologres V1.1.24 e posterior, o limite de 20 GB por nó é removido para nós worker. A memória para computação é alocada dinamicamente com base no uso do nó para garantir consultas bem-sucedidas. Se ocorrer um erro de falta de memória na V1.1.24 ou posterior apesar de um plano de execução válido, otimize as instruções SQL ou escale verticalmente a instância.

  Nota

  O backend de uma instância do Hologres consiste em múltiplos nós. O número de nós contidos em uma instância do Hologres varia com base nas especificações da instância. A memória máxima é de 64 GB para um único nó. A memória de um nó é alocada uniformemente para computação, caches, metadados e processos residentes.

  V1.1 (Outubro de 2021)

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

    O Auto-analyze, introduzido na V0.10 e comprovado em produção, está habilitado 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 mais informações sobre como usar o recurso auto-analyze, consulte ANALYZE e AUTO ANALYZE.

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

    O recurso resharding, introduzido na V0.10 e comprovado em produção, teve uma 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 mais informações sobre como usar o recurso resharding, consulte Gerenciar grupos de tabelas e shards.

    • Para mais informações sobre como usar grupos de tabelas, consulte Melhores práticas para configuração de grupos de tabelas.

  • 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 escaneadas 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 mais informações, consulte Exportar dados para o MaxCompute.

    Para mais informações sobre os parâmetros, consulte Acelerar consultas do MaxCompute.

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

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

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

    No Hologres V1.1 e posterior, 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 mais informações, consulte Gerenciar conexões.

  • 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, 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 mais informações, consulte Gerenciar consultas.