This topic describes the default behavior changes in each version of Hologres.

Note Parameter names are backward compatible. If the name of a parameter is changed in a later version, the original parameter name can still be used. However, we recommend that you use the new parameter name.

Default behavior changes in Hologres V1.3 released in July 2022

Specific features are optimized.
  • The public preview of JSON-related features is complete. The features are officially released.
  • The public preview of PostGIS-related features is complete. The features are officially released.
  • When you insert data by using a method such as Data Integration or Flink, we recommend that you use SQL statements instead of SDKs to write data.

Default behavior changes in Hologres V1.1 released in July 2022

To improve the self-diagnosis and self-O&M capabilities of Hologres, a number of monitoring metrics are added in Hologres in July 2022. These metrics allow you to more accurately identify issues and view resource usage. This improves the overall availability of Hologres. You must take note of the following items:
  • The monitoring metrics added in July 2022 are applicable only to Hologres V1.1 and later. If your Hologres instance is of an earlier version, submit a ticket to update your instance.
  • The CPU and memory metrics are calculated more accurately to help you better determine the resource usage. Therefore, after the new metrics are released in July 2022, the CPU utilization and memory usage of Hologres instances in V1.1 may fluctuate between 5% and 10%. The CPU utilization and memory usage of Hologres instances also fluctuate in CloudMonitor. Pay attention to the alert information in CloudMonitor and set appropriate monitoring thresholds again.
For more information about the monitoring metrics, see Hologres metrics.

Default behavior changes in Hologres V1.1 released in April 2022

The memory usage is optimized.

In Hologres V1.1.53 and later, the memory usage is optimized. O&M metrics are reported in an optimized way at the backend, which occupies fewer memory resources and leaves more memory resources for computing. You can update the version of your Hologres instance to V1.1.53 based on your business requirements.

Default behavior changes in Hologres V1.1 released in March 2022

The performance of point queries initiated by using fixed plans is optimized.

In Hologres V1.1.49 and later, the performance of point queries initiated by using fixed plans is optimized. In point queries that involve large amounts of data, the throughput is improved by more than 30%. You can update the version of your Hologres instance to V1.1.49 or later based on your business requirements. For more information about fixed plans, see Accelerate the execution of SQL statements by using fixed plans.

Default behavior changes in Hologres V1.1 released in March 2022

Properties are verified when a child partitioned table is attached to a parent partitioned table.

In Hologres V1.1.42 and later, the properties of a child partitioned table are strictly verified against those of a parent partitioned table after you initiate a request to attach the child partitioned table to the parent partitioned table. If a property of the child partitioned table is not consistent with that of the parent partitioned table, an error is reported and the attach operation fails. The properties that the system verifies include the primary keys, indexes, and the NOT NULL constraint. Before you create a child partitioned table, make sure that the properties of the child partitioned table are consistent with those of the parent partitioned table. For more information, see CREATE PARTITION TABLE.

The following code provides a sample scenario in which the clustering key of the child partitioned table is not consistent with that of the parent partitioned table. In this case, the child partitioned table fails to be attached to the parent partitioned table.
-- The following DDL statements show the definition of an existing parent partitioned table and its child partitioned 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';

-- Delete the original child partitioned table and attach the temporary child partitioned table to the parent partitioned 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 ;

-- Cause of error
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.
                

Default behavior changes in Hologres V1.1 released in December 2021

By default, the public endpoint of a new Hologres instance is disabled.

To meet the security requirements for data access control, the public endpoints of new Hologres instances are disabled by default from 00:00:00 December 7, 2021. By default, Internet access capabilities are not provided. If you want to connect to your Hologres instance by using the public endpoint, you can enable the public endpoint in the Hologres console.

Default behavior changes in Hologres V1.1 released in November 2021

The maximum memory used for computing is no longer limited to 20 GB per node.

In Hologres V1.1.24 and later, the limit is not applicable to worker nodes and the memory used for computing is dynamically allocated to each node. The memory usage of a worker node is continuously monitored at the Hologres backend. This way, the memory used for computing can be dynamically allocated to the node based on its memory usage to ensure successful queries. If the execution plan is valid but an error message appears to inform you that the memory usage exceeds the limit when you execute queries in Hologres V1.1.24 or later, you must optimize the SQL statements or scale up the Hologres instance.
Note The backend of a Hologres instance consists of multiple nodes. The number of nodes contained in a Hologres instance varies based on the specifications of the instance. The maximum memory is 64 GB for a single node. The memory of a node is evenly allocated to computing tasks, caches, and metadata and resident processes.

Default behavior changes in Hologres V1.1 released in October 2021

  • By default, the auto-analyze feature is enabled.
    The auto-analyze feature is introduced in Hologres V0.10. This feature has been verified by users online and proven to be usable in production environments. As of Hologres V1.1, the auto-analyze feature is enabled by default. The status of the auto-analyze feature remains unchanged in Hologres instances that are updated to V1.1. For new instances that are created in Hologres V1.1, the auto-analyze feature is enabled by default. In addition, the relevant parameter name is changed in Hologres V1.1, as described in the following table.
    Original parameter name New parameter name Default value
    hg_experimental_enable_start_auto_analyze_worker hg_enable_start_auto_analyze_worker on
    For more information about how to use the auto-analyze feature, see ANALYZE and auto-analyze.
  • The name of a table group-related function is changed.
    The resharding feature is introduced in Hologres V0.10. This feature has been verified by users online and proven to be usable in production environments. In Hologres V1.1, the name of a table group-related function is changed, as described in the following table.
    Original function name New function name
    hg_update_table_shard_count('table_name','table_group_name') hg_move_table_to_table_group('table_name','table_group_name')
  • The engine for accelerated access to MaxCompute tables in Hologres is changed.
    A new engine for accelerated access to MaxCompute tables is introduced in Hologres V0.10. This engine improves performance by more than 30%. The engine has been verified by users online and proven to be usable in production environments. As of Hologres V1.1, this new engine is used as the default engine for accelerated access to MaxCompute tables. The engine for accelerated access to MaxCompute tables remains unchanged in Hologres instances that are updated to V1.1. For new instances that are created in Hologres V1.1, the new engine is used by default. In addition, the relevant parameter names are changed in Hologres V1.1, as described in the following table.
    Original parameter name New parameter name Description
    hg_experimental_enable_access_odps_orc_via_holo hg_enable_access_odps_orc_via_holo Default value: on.
    hg_experimental_foreign_table_executor_max_dop hg_foreign_table_executor_max_dop The default value is changed to the number of CPU cores of an instance. The maximum value is 128.
    N/A hg_foreign_table_executor_dml_max_dop This parameter is added in Hologres V1.1. Default value: 32. This parameter applies to DML statements that are related to foreign tables.
    hg_experimental_foreign_table_split_size hg_foreign_table_split_size Unit: MB. Default value: 64.
    hg_experimental_foreign_table_max_partition_limit hg_foreign_table_max_partition_limit Default value: 512. A maximum of 512 partitions can be scanned for a query.
    hg_experimental_enable_write_maxcompute N/A In Hologres V1.1, the default value is on. This allows data to be written back to MaxCompute. For more information, see Export data to MaxCompute by executing SQL statements.
    For more information about the parameters, see Optimize the performance of querying MaxCompute tables in Hologres.
  • The pg_stat_activity view records the status of active connections for all frontend nodes.

    In versions earlier than Hologres V1.1, the pg_stat_activity view records the status of active connections only for a single frontend node. This makes it inconvenient to check and process active queries. As of Hologres V1.1, the pg_stat_activity view records the status of active connections for all frontend nodes. For more information about how to manage active queries by using the pg_stat_activity view, see Manage queries.

  • The connection management mechanism is adjusted.

    As of Hologres V1.1, connections are reserved for superusers. In addition, the logic of the HoloWeb connection pool is optimized. This allows superusers to connect to a Hologres instance by using HoloWeb and manage or release connections if the number of connections exceeds the number allowed by the specifications of the instance. For more information, see Manage connections.

  • The default value of the idle_in_transaction_session_timeout parameter is changed.

    The idle_in_transaction_session_timeout parameter specifies the timeout behavior after a transaction enters the idle state. If you do not set this parameter, a transaction that times out is not rolled back. As a result, deadlocks may occur during queries. As of Hologres V1.1, the idle_in_transaction_session_timeout parameter specifies a timeout period of 10 minutes by default. For more information, see Manage queries.

  • DML and DDL statements cannot be executed in the same transaction.
    In Hologres, transactions support only DDL statements. If a transaction contains DML statements, transaction resources are consumed and more potentially unstable states may occur. As of Hologres V1.1, the insert in ddl transaction is not supported now error message is reported if you write both DML and DDL statements in a transaction. The following statements provide an example:
    begin;
    create table abc(id int);
    insert into abc values(1); -- The "insert in ddl transaction is not supported now" error message is reported.
    commit;
    Note If your existing transactions contain both DML and DDL statements, you can execute the following statement to set the hg_experimental_enable_dml_in_ddl_transaction_block parameter to on for your database. This allows the database to be compatible with these transactions in Hologres V1.1.
    alter database <db_name> set hg_experimental_enable_dml_in_ddl_transaction_block = on; -- Replace <db_name> with the name of your database.