Hologres:Default behavior changes

V4.2

V4.1

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

V4.0 (septiembre de 2025)

V3.2 (agosto de 2026)

• Cambio en la cantidad predeterminada de hilos de servicio RPC para consultas de tablas externas de MaxCompute

  Qué cambió: A partir de Hologres V3.2.42, el valor predeterminado del parámetro de hilos de servicio RPC holo_seahawks_rpc_service_thread_number cambió de 300 a 150.

  Impacto: Las consultas de tablas externas de MaxCompute que se ejecutan en el motor SQE con un QPS alto presentan un aumento moderado de latencia. A cambio, la instancia funciona de manera más estable: las consultas de tablas externas ya no compiten por los recursos de las consultas de tablas internas ni degradan su rendimiento, lo que mejora el estado general de la instancia.

  Recomendación: Actualice la instancia a Hologres V4.1 o posterior. A partir de esa versión, las consultas de tablas externas se ejecutan en un motor nuevo que ofrece un mejor rendimiento de consulta y mantiene la estabilidad.

• Nuevo límite en la cantidad de archivos leídos desde una sola tabla externa de MaxCompute

  Qué cambió: A partir de Hologres V3.2.43, se agregó un nuevo parámetro GUC hg_experimental_maxcompute_sdk_split_total_file_count_limit con un valor predeterminado de 100,000. Si una sola tabla externa de MaxCompute lee más archivos que este límite dentro de una consulta, la consulta termina con errores. Antes de este cambio, el parámetro no existía y la cantidad de archivos leídos desde una sola tabla era ilimitada.

  Impacto: Cargas de trabajo que consultan tablas externas de MaxCompute, especialmente aquellas que contienen una gran cantidad de archivos pequeños. Las consultas que superan el límite se bloquean, lo que evita que un uso excesivo de memoria desencadene un error OOM y afecte otras cargas de trabajo en la instancia.

  Recomendación: Combine primero los archivos pequeños en MaxCompute para reducir la cantidad de archivos que lee cada consulta. Si combinar los archivos pequeños no es viable por ahora, puede aumentar hg_experimental_maxcompute_sdk_split_total_file_count_limit después de evaluar los recursos restantes de la instancia. Un valor más alto incrementa el nivel de consumo de memoria de la instancia. Establézcalo de forma conservadora según su carga de trabajo real y mantenga el monitoreo del uso de memoria después del ajuste.

V3.2 (julio de 2025)

• Se agregaron palabras clave no reservadas como Branch, Overwrite, Parameter y Tag; además, se agregaron palabras clave reservadas como Lambda y Qualify. Para obtener información sobre las palabras clave, consulte Palabras clave de PostgreSQL.

• A partir de Hologres V3.2, se admite la optimización adaptable para CTE. La estrategia de materialización de CTE se determina mediante dos parámetros GUC: optimizer_cte_inlining y hg_cte_strategy. Estos parámetros son independientes entre sí y se pueden configurar por separado, sin importar el orden de configuración. Los comportamientos son los siguientes:

  • Cuando optimizer_cte_inlining = off, los CTE se reutilizan, sin importar la configuración de hg_cte_strategy.

  • Cuando optimizer_cte_inlining = on, los CTE ya no se insertan en línea de forma obligatoria. La directiva de CTE se determina mediante hg_cte_strategy:

    • Si hg_cte_strategy = auto (valor predeterminado), el optimizador de consultas (QO) selecciona automáticamente si inserta en línea o reutiliza el CTE según factores como su complejidad.

    • Cuando hg_cte_strategy = inlining, los CTE se insertan en línea de forma obligatoria.

    • Cuando hg_cte_strategy = reuse, los CTE se reutilizan de forma obligatoria.

• A partir de Hologres V3.2, Fast Rows está habilitado de forma predeterminada. Cuando una tabla carece de estadísticas, el optimizador obtiene automáticamente el conteo real de filas para generar un mejor plan de ejecución.

  Este comportamiento es automático tras la actualización y no requiere configuración. Para obtener más detalles, consulte ANALYZE and AUTO ANALYZE.

V3.1 (agosto de 2026)

• Cambio en la cantidad predeterminada de hilos de servicio RPC para consultas de tablas externas de MaxCompute

  Qué cambió: A partir de Hologres V3.1.53, el valor predeterminado del parámetro de hilos de servicio RPC holo_seahawks_rpc_service_thread_number cambió de 300 a 150.

  Impacto: Las consultas de tablas externas de MaxCompute que se ejecutan en el motor SQE con un QPS alto presentan un aumento moderado de latencia. A cambio, la instancia funciona de manera más estable: las consultas de tablas externas ya no compiten por los recursos de las consultas de tablas internas ni degradan su rendimiento, lo que mejora el estado general de la instancia.

  Recomendación: Actualice la instancia a Hologres V4.1 o posterior. A partir de esa versión, las consultas de tablas externas se ejecutan en un motor nuevo que ofrece un mejor rendimiento de consulta y mantiene la estabilidad.

• Nuevo límite en la cantidad de archivos leídos desde una sola tabla externa de MaxCompute

  Qué cambió: A partir de Hologres V3.1.53, se agregó un nuevo parámetro GUC hg_experimental_maxcompute_sdk_split_total_file_count_limit con un valor predeterminado de 100,000. Si una sola tabla externa de MaxCompute lee más archivos que este límite dentro de una consulta, la consulta termina con errores. Antes de este cambio, el parámetro no existía y la cantidad de archivos leídos desde una sola tabla era ilimitada.

  Impacto: Cargas de trabajo que consultan tablas externas de MaxCompute, especialmente aquellas que contienen una gran cantidad de archivos pequeños. Las consultas que superan el límite se bloquean, lo que evita que un uso excesivo de memoria desencadene un error OOM y afecte otras cargas de trabajo en la instancia.

  Recomendación: Combine primero los archivos pequeños en MaxCompute para reducir la cantidad de archivos que lee cada consulta. Si combinar los archivos pequeños no es viable por ahora, puede aumentar hg_experimental_maxcompute_sdk_split_total_file_count_limit después de evaluar los recursos restantes de la instancia. Un valor más alto incrementa el nivel de consumo de memoria de la instancia. Establézcalo de forma conservadora según su carga de trabajo real y mantenga el monitoreo del uso de memoria después del ajuste.

V3.1 (mayo de 2025)

• Tablas dinámicas:

  • Sintaxis

    A partir de Hologres V3.1, las tablas dinámicas usan una sintaxis nueva y más concisa. Después de actualizar a V3.1 las tablas dinámicas creadas en V3.0, solo se pueden ejecutar operaciones ALTER en una tabla que use actualización completa de datos. Para crear una tabla nueva, debe usar la sintaxis de V3.1. En el caso de una tabla que use actualización incremental de datos, debe volver a crearla con la sintaxis nueva. Para obtener más información, consulte Create dynamic table.

  • Uso de recursos

    • Recursos de actualización

      Las tablas dinámicas creadas en Hologres V3.1 usan de forma predeterminada recursos de serverless computing para ejecutar tareas. Si la instancia actual no tiene habilitado Serverless Computing, recurrirá automáticamente a los recursos de la instancia. Las tablas creadas en Hologres V3.0 continúan usando los recursos especificados al momento de su creación. Para obtener más información, consulte Create dynamic table.

    • Creación de tablas con recursos de la instancia

      • Sintaxis nueva (Hologres V3.1 y V3.2): Se usan los almacenes de datos virtuales principales de los grupos de tablas de la tabla base y de la tabla dinámica.

      • Sintaxis anterior (Hologres V3.0) y sintaxis nueva (Hologres V4.1): Se usa el almacén de datos virtual principal del grupo de tablas de la tabla dinámica.

  • Conteo de conexiones

    La sintaxis nueva mantiene una conexión adicional por cada tabla dinámica. Si su instancia tiene un uso alto de conexiones y cientos de tablas dinámicas, elimine las conexiones inactivas para evitar problemas.

  • Métodos para leer datos incrementales de la tabla base

    A partir de Hologres V3.1 y versiones posteriores, se usa el método stream para identificar los cambios de datos en la tabla base. En comparación con el registro binario, el método stream ofrece mayor rendimiento y es más rentable. Después de actualizar su instancia a V3.1, el método stream se usa de forma predeterminada. Si el registro binario está habilitado para su tabla en V3.0, deshabilítelo a la brevedad para evitar costos de almacenamiento adicionales. Para obtener más información, consulte Dynamic tables.

• La función de cola de consultas completó la fase Beta y está disponible para entornos de producción. Para obtener más información, consulte Query queue.

• TRUNCATE ahora es una instrucción DML (antes DDL), lo que reduce la presión en el nodo FE. Para volver al comportamiento DDL, deshabilite el parámetro GUC hg_enable_truncate_as_dml. Sin embargo, al ejecutar una operación TRUNCATE en una tabla con registro binario habilitado, debe deshabilitar el registro binario a nivel de sesión. Para obtener más información, consulte TRUNCATE.

• Cuando importa datos a una tabla con clave primaria mediante COPY, el parámetro GUC hg_experimental_copy_enable_on_conflict está habilitado de forma predeterminada. Esto le permite establecer directivas de actualización de datos al importar datos a tablas con claves primarias. Para obtener más información, consulte COPY.

• Cuando usa la función hg_insert_overwrite, la cantidad de columnas y sus tipos de datos especificados en la instrucción SQL (instrucción SELECT estándar) deben coincidir estrictamente con los de la tabla de destino (tabla interna de Hologres). De lo contrario, se reporta el mensaje de error error: table "hg_alias" has x columns available but x columns specified o error: column xx is of type xxx but expression is of type xxx. Para obtener más información, consulte INSERT OVERWRITE.

• Se actualizó la tabla del sistema hg_table_storage_status. A partir de Hologres V3.1, la tabla del sistema ya no incluye los datos de tablas almacenados en memoria (tabla de memoria). En su lugar, refleja únicamente el almacenamiento físico real de las tablas. Para obtener más información sobre el mecanismo de tablas de memoria, consulte INSERT.

• Se agregaron las siguientes palabras clave no reservadas: async, logical, purge, recover, rebuild, resume y suspend. Consulte Palabras clave de 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 (julio de 2024)

Cuando se utiliza Java Database Connectivity (JDBC) para consumir los registros binarios de Hologres, el número máximo de walsenders disponibles para un worker se reduce de 1,000 a 600. La cantidad de walsenders se calcula con base en el número de slots. Para obtener más información, consulte Consume Binlog via JDBC. Se recomienda usar el modo jdbc_fixed para consumir los registros binarios de Hologres. A diferencia del consumo de registros en modo JDBC, el modo jdbc_fixed no ocupa conexiones y no está sujeto a límites en la cantidad de walsenders. Para conocer más detalles sobre el modo jdbc_fixed, consulte Hologres SQL connector.

V2.2 (junio de 2024)

En Hologres V2.2 y versiones posteriores, la capacidad subyacente de recopilación de registros de consultas lentas se actualiza automáticamente. Esto permite que Hologres registre más información sobre dichas consultas. De este modo, el personal de negocio puede gestionar con mayor precisión las operaciones según el estado de las consultas ejecutadas en las instancias de Hologres. Para obtener más información sobre los registros de consultas lentas, consulte Get and analyze slow query logs. La recopilación de estos registros presenta las siguientes mejoras:

• Ahora se registran las consultas que fallan por causas como sintaxis no válida, errores al analizar sintácticamente el plan o permisos insuficientes. En versiones anteriores a Hologres V2.2, estas consultas no se registraban. Se recomienda utilizar la función SQL diagnostics para gestionar las consultas con errores.

• Si una transacción contiene varias instrucciones de lenguaje de definición de datos (DDL), como BEGIN; DROP TABLE xxx; COMMIT;, toda la transacción se registra como un solo registro de consulta en los registros de consultas lentas. Sin embargo, la métrica Query QPS cuenta la transacción como varias instrucciones DDL. Por ejemplo:

  -- 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;

  • El siguiente código de ejemplo muestra el resultado en los registros de consultas lentas:

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

  • El siguiente código de ejemplo muestra el resultado en el sistema de monitoreo:

    Query QPS: 4 records
    Failed Query QPS: 1 record

V2.2 (mayo de 2024)

• En Hologres V2.2 y versiones posteriores, las propiedades de tabla que devuelve hg_dump_script se muestran con la sintaxis WITH en lugar de la sintaxis CALL. Este cambio mejora la practicidad y legibilidad de la instrucción CREATE TABLE. Para obtener más información, consulte la sección "Consultar el esquema de una tabla" en Overview.

• En Hologres V2.2.7 y versiones posteriores, el valor predeterminado cambia de 1 segundo a 100 milisegundos. Tras esta modificación, los registros de consultas lentas capturan las instrucciones SQL que tardan más de 100 milisegundos en lugar de 1 segundo. Estas instrucciones incluyen INSERT, SELECT, UPDATE y DELETE. Para obtener más información, consulte Get and analyze slow query logs.

• En Hologres V2.2.9 y versiones posteriores, los resultados que devuelve point queries of key-value pairs by using fixed plans ya no se ordenan según la clave primaria de la cláusula WHERE.

  Ejemplo de consultas puntuales mediante 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)

• En Hologres V2.2 y versiones posteriores, Hologres usa un rol vinculado al servicio de forma predeterminada para acceder a las tablas externas de MaxCompute. Al comprar una instancia o actualizarla a la V2.2 o posterior, cree el rol vinculado al servicio y otórguele los permisos obligatorios. Estos roles permiten el acceso autorizado entre servicios y previenen riesgos por malas configuraciones. Para obtener más información, consulte Service-linked role for Hologres.

• En Hologres V2.2 y versiones posteriores, la directiva predeterminada del optimizador cambia de exhaustive a exhaustive2. Esto mejora el rendimiento entre un 20 % y un 40 % en la mayoría de los casos. En las consultas left outer join, el plan podría ser subóptimo y generar un mayor uso de memoria. Para revertir este cambio, ejecute set optimizer_join_order = 'exhaustive'; y vuelva a exhaustive.

• En Hologres V2.2 y versiones posteriores, el valor de Engine Type para los procesos que usan fixed plans cambia de SDK a FixedQE en los registros de consultas lentas. Con esto se garantiza la consistencia de nombres entre los registros de consultas lentas y las métricas.

• En Hologres V2.2 y versiones posteriores, el número de conexiones hacia un nodo FE aumenta de 128 a 256, por lo que el total de conexiones se duplica. Para obtener más información, consulte Instance management.

• INSERT OVERWRITE y BSI functions ya están disponibles de forma general.

• En Hologres V2.2 y versiones posteriores, la instrucción SELECT hg_dump_script() devuelve las propiedades de creación de tablas con la sintaxis WITH en lugar de la sintaxis CALL. Este cambio mejora la practicidad y legibilidad al crear tablas. Para obtener más información, consulte View a table schema.

V2.1 (junio de 2024)

En Hologres V2.1.27 y versiones posteriores, si utiliza Realtime Compute for Apache Flink con VVR 8.0.7 o superior para consumir los registros binarios de Hologres, el modo JDBC se actualiza automáticamente al modo jdbc_fixed. A diferencia de las consultas en modo JDBC, las consultas en modo jdbc_fixed no consumen conexiones y su rendimiento no está limitado por el número máximo de walsenders. Para obtener más información sobre el modo jdbc_fixed, consulte Hologres SQL connector. Para conocer más detalles sobre el modo JDBC, consulte Consume Binlog via JDBC.

V2.1 (marzo de 2024)

Al usar Realtime Compute for Apache Flink para consumir los registros binarios de Hologres, el modo HoloHub deja de ser compatible y la configuración 'sdkMode'='holohub' pierde validez. Solo se admite el modo Java Database Connectivity (JDBC). El modo JDBC es más estable que el modo HoloHub y admite más tipos de datos. Antes de actualizar su instancia de Hologres a la V2.1, utilice una de las siguientes soluciones para revisar el despliegue de Realtime Compute for Apache Flink y su instancia de Hologres. Así se asegurará de que el despliegue funcione correctamente. Para obtener más información, consulte Consume Binlog via JDBC.

• Solución 1 (recomendada): actualice la versión VVR de Realtime Compute for Apache Flink a la 8.0.7 o posterior y después actualice su instancia de Hologres. De esta manera, Realtime Compute for Apache Flink cambiará automáticamente del modo HoloHub al modo JDBC.

• Solución 2: actualice la versión VVR de Realtime Compute for Apache Flink a cualquier versión entre la 6.0.7 y la 8.0.5. Luego, agregue la configuración 'sdkMode'='jdbc' a la tabla de origen de Realtime Compute for Apache Flink y reinicie el despliegue. Otorgue uno de los siguientes conjuntos de permisos a la cuenta de usuario con la que inicia sesión en la instancia de Hologres. Una vez que confirme que el despliegue funciona correctamente, actualice su instancia de Hologres.

  • Permisos de superusuario en la instancia de Hologres.

  • Los permisos del propietario de la tabla, el permiso CREATE DATABASE y los permisos del rol de replicación de la instancia de Hologres.

• Solución 3 (no recomendada): actualice la versión VVR de Realtime Compute for Apache Flink a la 8.0.6 y luego actualice su instancia de Hologres. En este caso, Realtime Compute for Apache Flink cambiará automáticamente del modo HoloHub al modo JDBC. La versión VVR 8.0.6 de Realtime Compute for Apache Flink tiene un defecto conocido: si las tablas de dimensiones contienen demasiados campos, los borradores de despliegue fallan por tiempo de espera agotado. Para obtener más información, consulte la sección "Notas de la versión del conector de Hologres" en Overview.

• Opcional: si tiene muchos despliegues de Realtime Compute for Apache Flink basados en VVR, obtenga información sobre ellos y sus tablas siguiendo las instrucciones de Use Realtime Compute for Apache Flink or Blink to consume Hologres binary logs in real time.

V2.1 (febrero de 2024)

En Hologres V2.1.19 se corrigieron las operaciones de multiplicación y división de datos de tipo DECIMAL. En versiones anteriores a la V2.1.19, las operaciones básicas con datos DECIMAL admitían un máximo de 18 decimales. Si el resultado de una multiplicación o división superaba los 18 decimales, los datos se truncaban antes del cálculo, lo que generaba un resultado no válido.

Por ejemplo, al multiplicar dos valores decimales, el número total de dígitos antes y después del punto decimal (precision_ans) y la cantidad de decimales (scale_ans) del resultado se calculan con las siguientes fórmulas:

precision_ans = precision_l + precision_r
scale_ans  = scale_l + scale_r

Si el valor de scale_ans supera 18, solo se conservan 18 decimales. Los valores decimales utilizados en la multiplicación se truncan hasta alcanzar la cantidad de decimales especificada según las siguientes reglas:

• Si scale_l ≤ 9, el valor decimal correspondiente no se trunca y conserva scale_l decimales para la multiplicación.

• Si scale_l > 9, el valor decimal correspondiente se trunca a la cantidad de decimales que devuelve max(9,18-scale_r).

• Si scale_r ≤ 9, el valor decimal correspondiente no se trunca y conserva scale_r decimales para la multiplicación.

• Si scale_r > 9, el valor decimal correspondiente se trunca a la cantidad de decimales que devuelve max(9,18-scale_l).

A continuación se muestra un ejemplo de código:

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;

• En versiones anteriores a la V2.1.19, si un factor tenía más de 9 decimales significativos, se truncaba a la cantidad de decimales especificada, lo que afectaba negativamente la precisión y generaba un resultado no vá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

• En Hologres V2.1.19 y versiones posteriores, este problema está corregido. La multiplicación se efectúa con los valores decimales originales y el resultado se trunca después a la cantidad de decimales especificada, lo que garantiza una alta precisión.

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

V2.1 (octubre de 2023)

Se optimizaron varias funciones.

• En Hologres V2.1.12 y versiones posteriores, si usa la función fixed plan para escribir datos en una columna de tipo DECIMAL sin especificar la precisión, y la precisión de los datos de origen es mayor que la de la columna de destino, Hologres redondea los datos de origen según la precisión de dicha columna. En Hologres V2.1.11 y versiones anteriores, Hologres trunca los datos de origen según la precisión de la columna de destino. Las siguientes instrucciones sirven como ejemplo.

  Nota

  En Hologres V2.1.12 y versiones posteriores, el proceso es el mismo independientemente de si se utiliza la función fixed plan.

  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);

• Data map, data lineage y Transmission Encryption concluyeron la fase Beta y ya están disponibles de forma general.

• Se actualizaron los requisitos de permisos para consumir el Binlog de Hologres. Ahora solo se requiere el permiso de lectura sobre la tabla de destino. Para obtener más información, consulte Consume Binlog via JDBC.

• Si utiliza Bulkload para importar datos a una tabla interna de Hologres que no tiene clave de distribución, el rendimiento de importación podría degradarse.

• En Hologres V2.1 y versiones posteriores, se admite la sintaxis CREATE TABLE WITH PROPERTY para simplificar la configuración de las propiedades de tabla. Para obtener más información, consulte CREATE TABLE.

• En Hologres V2.1 y versiones posteriores, se modificó la directiva de compactación para las operaciones DELETE y UPDATE con el fin de recuperar oportunamente los archivos marcados. Esto puede reducir el almacenamiento y mejorar el rendimiento de las consultas en tablas orientadas a columnas con operaciones DELETE y UPDATE frecuentes. Después de actualizar a la V2.1, la compactación en segundo plano de archivos pequeños históricos consume una cantidad considerable de CPU. Dependiendo del volumen de archivos, este proceso puede tardar más de 10 minutos o incluso varias horas.

• En Hologres V2.1 y versiones posteriores, se agregó un mecanismo para comprobar si todas las columnas especificadas en CONFLICT dentro de la sintaxis INSERT INTO <table_name> ON CONFLICT(<col_name>,...) DO son columnas de clave primaria. Si alguna columna no es de clave primaria, la ejecución de la instrucción SQL falla. Para obtener más información, consulte INSERT ON CONFLICT (UPSERT).

• En Hologres V2.1 y versiones posteriores, la extensión dlf_fdw se crea de forma predeterminada para que pueda acceder a lagos de datos mediante tablas externas. Ya no es necesario crear manualmente la extensión dlf_fdw. Tampoco se requiere especificar el parámetro dlf_region al crear un servidor externo; basta con especificar los parámetros dlf_endpoint, oss_endpoint y dlf_catalog. Además, se incorporó una validación de formato para los parámetros dlf_endpoint y oss_endpoint para evitar errores. Los formatos requeridos son los siguientes:

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

  • oss_endpoint:

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

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

• Las siguientes palabras clave ahora se utilizan como palabras clave no reservadas: system_time, proctime y dynamic. No puede usar palabras clave no reservadas como nombres de columna en instrucciones SQL; únicamente se permiten como alias y deben colocarse después de AS. Instrucciones de ejemplo:

  -- 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 (junio de 2023)

Se optimizaron varias funciones.

• Al usar Realtime Compute for Apache Flink para consumir los registros binarios de Hologres, se admite el modo JDBC. El modo HoloHub, especificado mediante la configuración 'sdkMode'='holohub', se descontinuará gradualmente. El modo JDBC es más estable que el modo HoloHub y admite más tipos de datos. Antes de actualizar su instancia de Hologres a la V2.0, utilice una de las siguientes soluciones para revisar el despliegue de Realtime Compute for Apache Flink y su instancia de Hologres. Así se asegurará de que el despliegue funcione correctamente. Para obtener más información, consulte Consume Binlog via JDBC.

  • Solución 1 (recomendada): actualice la versión VVR de Realtime Compute for Apache Flink a la 8.0.6 o posterior y luego actualice su instancia de Hologres. De esta manera, Realtime Compute for Apache Flink cambiará automáticamente del modo HoloHub al modo JDBC. La versión VVR 8.0.6 de Realtime Compute for Apache Flink tiene un defecto conocido: si las tablas de dimensiones contienen demasiados campos, los borradores de despliegue fallan por tiempo de espera agotado. Para obtener más información, consulte la sección "Notas de la versión del conector de Hologres" en Overview. Se recomienda actualizar la versión VVR de Realtime Compute for Apache Flink a la 8.0.7.

  • Solución 2: actualice la versión VVR de Realtime Compute for Apache Flink a la 8.0.4 o la 8.0.5 y reinicie el despliegue. Otorgue uno de los siguientes conjuntos de permisos a la cuenta de usuario con la que inicia sesión en la instancia de Hologres. Una vez que confirme que el despliegue funciona correctamente, actualice su instancia de Hologres.

    • Permisos de superusuario en la instancia de Hologres.

    • Los permisos del propietario de la tabla, el permiso CREATE DATABASE y los permisos del rol de replicación de la instancia de Hologres.

  • Solución 3: actualice la versión VVR de Realtime Compute for Apache Flink a cualquier versión entre la 6.0.7 y la 8.0.3, y después actualice su instancia de Hologres. En este escenario, Realtime Compute for Apache Flink seguirá usando el modo HoloHub para consumir los registros binarios de Hologres.

• Las tablas de dimensiones y las tablas de resultados de Realtime Compute for Apache Flink ya no admiten el modo de llamada a procedimiento remoto (RPC), especificado mediante las configuraciones 'sdkMode'='rpc' o 'rpcMode'='true'. En su lugar, se utiliza el modo JDBC. Antes de actualizar su instancia de Hologres a la V2.0, realice las siguientes operaciones para revisar el despliegue de Realtime Compute for Apache Flink y su instancia de Hologres. Así se asegurará de que el despliegue funcione correctamente. Para obtener más información, consulte Hologres SQL connector.

  • Si la versión VVR de Realtime Compute for Apache Flink es la 6.0.7 o posterior, el sistema cambia automáticamente del modo RPC al modo JDBC. No se requiere ninguna acción adicional.

  • Si la versión VVR de Realtime Compute for Apache Flink está entre la 6.0.3 y la 6.0.6, cambie la configuración 'sdkMode'='rpc' por 'sdkMode'='jdbc' o bien cambie 'rpcMode'='true' por 'rpcMode'='false' en los despliegues de Realtime Compute for Apache Flink.

  • Si la versión VVR de Realtime Compute for Apache Flink es la 6.0.2 o anterior, cambie la configuración 'rpcMode'='true' por 'rpcMode'='false' en los despliegues de Realtime Compute for Apache Flink.

  • Si las conexiones de su instancia de Hologres son insuficientes, se recomienda configurar el parámetro connectionPoolName para compartir conexiones en el pool de conexiones. También puede actualizar la versión VVR de Realtime Compute for Apache Flink a la 6.0.7 o posterior y usar la configuración 'sdkMode'='jdbc_fixed'. De este modo, no se ocupará ninguna conexión.

  • El modo RPC no deduplica los datos con la misma clave primaria dentro de un mismo lote, mientras que el modo JDBC los deduplica automáticamente. Si sus escenarios de negocio requieren conservar todos los datos, utilice la configuración 'jdbcWriteBatchSize'='1' para evitar la deduplicación.

• En Hologres V2.0 y versiones posteriores, ya no es posible usar Blink para ejecutar consultas puntuales en tiempo real sobre los datos de Hologres ni para escribir datos en este servicio. Se recomienda migrar sus despliegues de Blink a Realtime Compute for Apache Flink antes de actualizar su instancia de Hologres.

V2.0 (abril de 2023)

Se optimizaron varias funciones.

• En Hologres V2.0 y versiones posteriores, los datos en formato segment no pueden almacenarse en modo de almacenamiento orientado a columnas. Las instancias de Hologres que contienen datos en formato segment no se pueden actualizar a la V2.0 ni a versiones posteriores. Utilice la función hg_convert_segment_orc para convertir simultáneamente varias tablas en formato segment a tablas en formato Optimized Row Columnar (ORC). Para obtener más información, consulte Upgrade storage format of column-oriented table.

• Se estableció un límite máximo para la cantidad de shards de un grupo de tablas o de una instancia. Esto ayuda a prevenir el desperdicio de recursos provocado por un uso inadecuado de los grupos de tablas. Para obtener más información, consulte Manage table groups and shards.

• Los datos se escriben en DataHub mediante el modo JDBC en lugar del modo SDK. El modo JDBC es más estable que el modo SDK y admite más tipos de datos.

• La extensión de registro binario se configura de forma predeterminada. Cuando consuma datos de registros binarios en modo JDBC, no necesitará crear dicha extensión. Al consumir datos de registros binarios en modo JDBC, el número máximo de walsenders utilizables aumenta 10 veces. Para una instancia configurada con 32 núcleos de CPU, el máximo de walsenders pasa de 200 a 2,000. Los walsenders se contabilizan como slots. Para obtener más información, consulte Consume Binlog via JDBC.

• Después de actualizar su instancia de Hologres, la función auto-analyze se ejecuta en las tablas de las que no se ha recopilado información estadística. Este proceso consume recursos de CPU y puede tardar desde varios minutos hasta algunas horas, dependiendo de la cantidad de tablas sin información estadística.

• La vista previa pública de las funciones de copia de seguridad y restauración, así como de almacenamiento en niveles, concluyó. Ambas funciones ya pueden usarse en entornos de producción.

• La vista previa pública de la función de replicación a nivel de recurso compartido concluyó y ya puede usarse en entornos de producción. Para obtener más información, consulte Shard-level replication for high throughout.

• Se estandarizaron los parámetros que definen las propiedades de tabla. La sintaxis utilizada para configurar estas propiedades cuando los nombres de columna contienen letras mayúsculas cambió. Para obtener más información, consulte CREATE TABLE. La propiedad bitmap_columns ya no admite el valor auto. Este cambio no afecta el funcionamiento de las tablas existentes.

• La función HG_CREATE_TABLE_LIKE ahora puede heredar índices creados, columnas de tipo de datos SERIAL y columnas con índices vectoriales proxima.

V1.3 (junio de 2023)

• En Hologres V1.3.53 y versiones posteriores, el recuento de réplicas debe ser menor o igual que la cantidad de workers. Para obtener más información, consulte Shard-level replication for high throughout (Beta).

• Se optimizó el resultado de cálculo de la función Avg. En versiones de Hologres anteriores a la V1.3, la función Avg devolvía el resultado con un máximo de seis decimales. Si el resultado contenía más de seis decimales, se truncaba. En Hologres V1.3 y versiones posteriores, la función Avg devuelve el resultado con todos sus decimales intactos.

• Se optimizó la visualización del valor de tipo TEXT convertido a partir de un valor de tipo DECIMAL. En versiones de Hologres anteriores a la V1.3.46, este valor se mostraba en notación científica. En Hologres V1.3.46 y versiones posteriores, el valor de tipo TEXT convertido se muestra directamente. Instrucciones SQL de ejemplo:

  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

Cambios en el comportamiento predeterminado de Hologres V1.3 publicada en febrero de 2023

Se optimizaron varias funciones.

En Hologres V1.3.36 y versiones posteriores, puede crear una vista entre esquemas mediante el modelo de permisos a nivel de esquema (SLPM). Para obtener más información, consulte Use the SLPM.

V1.3 (enero de 2023)

Se optimizaron varias funciones.

• En Hologres V2.0 y versiones posteriores, las tablas en formato segment dejan de ser compatibles. En Hologres V1.3.35 y versiones posteriores, se proporciona una instrucción para convertir simultáneamente varias tablas en formato segment a tablas en formato ORC. Esta conversión facilita la migración de los datos de las tablas existentes. Para obtener más información, consulte Upgrade storage format of column-oriented table. Las instancias de Hologres que contienen datos en formato segment no se pueden actualizar a una versión posterior.

• En Hologres V1.3.35 y versiones posteriores, más parámetros de Grand Unified Configuration (GUC) para la función fixed plan se establecen de forma predeterminada en on. Esto mejora la usabilidad y el rendimiento del sistema. Para obtener más información, consulte Accelerate SQL execution with fixed plans.

V1.3 (diciembre de 2022)

Se optimizaron varias funciones.

• A partir del December 26, 2022, Alibaba Cloud dejó de proporcionar endpoints de virtual private cloud (VPC) para las nuevas instancias, incluidas aquellas creadas mediante la función de copia de seguridad o restauración. Puede especificar endpoints de VPC más seguros. El endpoint de VPC que especifique se conectará únicamente a la VPC seleccionada al comprar la instancia de Hologres, lo que ofrece mayor seguridad y aislamiento. Las instancias existentes no se ven afectadas. Se recomienda deshabilitar el endpoint de VPC original y especificar uno nuevo en su lugar.

• En Hologres V1.3.31 y versiones posteriores, puede cifrar datos en Hologres y consultar datos cifrados desde MaxCompute de forma predeterminada. Ya no es necesario aplicar configuraciones adicionales ni enviar un ticket. Para obtener más información, consulte Encrypt data at rest y Query encrypted MaxCompute data.

V1.3 (noviembre de 2022)

V1.3 (octubre de 2022)

V1.3 (septiembre de 2022)

V1.3 (julio de 2022)

V1.1 (julio de 2022)

V1.1 (abril de 2022)

Se optimizó el uso de memoria.

En Hologres V1.1.53 y versiones posteriores, se optimizó el uso de memoria y se mejoró la eficiencia en el reporte de las métricas de operación y mantenimiento del backend, lo que libera más memoria para el cómputo. Actualice a la V1.1.53 según sus necesidades de negocio.

V1.1 (marzo de 2022)

Se optimizó el rendimiento de las consultas puntuales que se inician mediante fixed plans.

En Hologres V1.1.49 y versiones posteriores, se optimizó el rendimiento de las consultas puntuales iniciadas mediante fixed plans. En las consultas puntuales que manejan un gran volumen de datos, el throughput mejora más del 30 %. Puede actualizar la versión de su instancia de Hologres a la V1.1.49 o posterior según sus necesidades de negocio. Para obtener más información sobre los fixed plans, consulte Accelerate SQL execution with fixed plans.

V1.1 (marzo de 2022)

Las propiedades se validan cuando una tabla secundaria se asocia a una tabla principal.

En Hologres V1.1.42 y versiones posteriores, las propiedades de una tabla secundaria y de una tabla principal se validan de forma estricta después de enviar una solicitud para asociar la tabla secundaria a la principal. Si alguna propiedad de la tabla secundaria no coincide con la de la tabla principal, el sistema reporta un error y la operación de asociación falla. Entre las propiedades que valida el sistema se incluyen las claves primarias, los índices y la restricción NOT NULL. Antes de crear una tabla secundaria, asegúrese de que sus propiedades coincidan con las de la tabla principal. Para obtener más información, consulte CREATE PARTITION TABLE.

-- 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 (diciembre de 2021)

El endpoint público de una nueva instancia de Hologres está deshabilitado de forma predeterminada.

Para cumplir con los requisitos de seguridad del control de acceso a los datos, desde las 00:00:00 del 7 de diciembre de 2021 los endpoints públicos de las nuevas instancias de Hologres se deshabilitan automáticamente. Por lo tanto, de forma predeterminada no proporcionan acceso a Internet. Si necesita conectarse a su instancia de Hologres mediante un endpoint público, habilítelo en la consola de Hologres.

V1.1 (noviembre de 2021)

La memoria máxima utilizada para el cómputo ya no está limitada a 20 GB por nodo.

V1.1 (octubre de 2021)

• La función auto-analyze se habilita de forma predeterminada.

  La función auto-analyze se introdujo en la V0.10 y ha demostrado su eficacia en entornos de producción. En la V1.1, se habilita de forma predeterminada para las instancias nuevas, mientras que las instancias actualizadas conservan su configuración existente. El nombre del parámetro también cambió en la V1.1:

  Nombre original del parámetro	Nuevo nombre del parámetro	Valor predeterminado
  hg_experimental_enable_start_auto_analyze_worker	hg_enable_start_auto_analyze_worker	on

  Para obtener más información sobre cómo usar la función auto-analyze, consulte ANALYZE and AUTO ANALYZE.

• Cambió el nombre de una función relacionada con un grupo de tablas.

  La función resharding se introdujo en la V0.10 y ha demostrado su eficacia en entornos de producción. En la V1.1, se renombró la función del grupo de tablas:

  Nombre original de la función	Nuevo nombre de la función
  hg_update_table_shard_count('table_name','table_group_name')	hg_move_table_to_table_group('table_name','table_group_name')

  • Para obtener más información sobre cómo usar la función resharding, consulte Manage table groups and shards.

  • Para obtener más información sobre cómo usar grupos de tablas, consulte Best practices for table group setup.

• Cambió el motor de acceso acelerado a tablas externas de MaxCompute en Hologres.

  Un nuevo motor de tablas externas de MaxCompute, introducido en la V0.10, mejora el rendimiento en más del 30 %. En la V1.1, este motor es el predeterminado para las instancias nuevas; las instancias actualizadas conservan su motor existente. Los nombres de los parámetros también cambiaron:

  Nombre original del parámetro	Nuevo nombre del parámetro	Observaciones
  hg_experimental_enable_access_odps_orc_via_holo	hg_enable_access_odps_orc_via_holo	Valor predeterminado: on.
  hg_experimental_foreign_table_executor_max_dop	hg_foreign_table_executor_max_dop	El valor predeterminado cambió al número de núcleos de CPU de una instancia. El valor máximo es 128.
  Ninguna	hg_foreign_table_executor_dml_max_dop	Este parámetro se agregó en Hologres V1.1. El valor predeterminado es 32. Se aplica a las instrucciones DML relacionadas con tablas externas.
  hg_experimental_foreign_table_split_size	hg_foreign_table_split_size	Valor predeterminado: 64. Unidad: MB.
  hg_experimental_foreign_table_max_partition_limit	hg_foreign_table_max_partition_limit	El valor predeterminado es 512. Indica que se pueden analizar hasta 512 particiones en una consulta.
  hg_experimental_enable_write_maxcompute	Ninguna	En Hologres V1.1, el valor predeterminado es on. Este valor indica que los datos se pueden escribir de vuelta en MaxCompute. Para obtener más información, consulte Export data to MaxCompute.

  Para obtener más información sobre los parámetros, consulte Accelerate MaxCompute queries.

• La tabla pg_stat_activity registra el estado de las conexiones activas de todos los nodos frontend.

  En versiones anteriores a la V1.1, pg_stat_activity registraba las conexiones activas de un solo nodo FE. En la V1.1, abarca todos los nodos FE. Para obtener más información sobre cómo gestionar consultas activas mediante la tabla pg_stat_activity, consulte Manage queries.

• Se ajustó el mecanismo de gestión de conexiones.

  En Hologres V1.1 y versiones posteriores, se reservan conexiones para el superusuario y se optimiza la lógica del pool de conexiones de HoloWeb. El superusuario puede usar HoloWeb para gestionar o liberar conexiones cuando se supera el límite establecido. Para obtener más información, consulte Manage connections.

• Cambió el valor predeterminado del parámetro idle_in_transaction_session_timeout.

  El parámetro idle_in_transaction_session_timeout define el tiempo de espera de las transacciones inactivas. Sin esta configuración, las transacciones que exceden el tiempo de espera no se revierten, lo cual genera riesgo de interbloqueos. En la V1.1, el valor predeterminado de idle_in_transaction_session_timeout es de 10 minutos. Para obtener más información, consulte Manage queries.