All Products
Search
Document Center

Hologres:Run read and write tasks with Serverless Computing

Last Updated:Feb 07, 2026

Hologres supports Serverless Computing in V2.1.17 and later. This topic describes how to run tasks using the Serverless Computing feature in Hologres.

Features supported by Serverless Computing

Serverless Computing supports the following task types:

  • Since Hologres V2.1.17, major DML tasks are supported, such as INSERT (excluding INSERT OVERWRITE), INSERT ON CONFLICT (UPSERT), DELETE, and UPDATE.

  • Since Hologres V2.2.14, Data Query Language (DQL) tasks are supported.

  • Since Hologres V3.0.1, COPY tasks in DML are supported.

  • Since Hologres V3.0.9, CREATE TABLE AS (CTAS) tasks in DML are supported.

  • Since Hologres V2.2.42/V3.0.19, RESHARDING tasks are supported.

  • Since Hologres V3.0.26, INSERT OVERWRITE tasks in DML are supported using the stored procedure hg_insert_overwrite. DML and DQL statements in stored procedures are also supported.

  • Since Hologres V3.1.0, native INSERT OVERWRITE syntax in DML and REBUILD tasks are supported.

  • Since Hologres V3.1.3, encrypted tables are supported for both read and write operations. These include Hologres internal encrypted tables and MaxCompute external encrypted tables. To read from or write to Hologres internal encrypted tables, you must enable the GUC parameter hg_serverless_computing_enable_encrypted_table. For more information, see Data encryption.

  • Since Hologres V3.1.11, compaction tasks are supported. For more information, see Run compaction tasks with Serverless Computing.

  • Since Hologres V4.0, DLF external tables are supported for both read and write operations. For supported file formats and other considerations, see Accelerate access to OSS data lakes with DLF.

Serverless Computing supports the following function extensions:

  • ClickHouse

  • Flow Analysis

  • PostGIS

  • RoaringBitmap

  • BSI

  • Proxima

Serverless Computing is not supported in the following cases:

  • Queries on read-only secondary instances. Primary instances and virtual warehouse instances function as expected.

  • Queries that use multi-statement DML transactions, such as when set hg_experimental_enable_transaction = on is enabled.

  • SQL statements that use Fixed Plans.

  • Cross-database queries or writes.

Run read and write tasks with Serverless Computing resources

Hologres lets you flexibly use Serverless Computing resources. You can direct individual SQL statements to Serverless resources or set rules to run batches of SQL statements on Serverless resources.

Hologres supports the following methods to route SQL statements to Serverless resources before execution. They take effect in descending order of priority:

  1. SQL level (session level): Set the hg_computing_resource parameter to 'serverless'. All read and write requests in the current connection are then run on Serverless resources.

  2. User level: Set the hg_computing_resource parameter to 'serverless' to execute using serverless resources.

  3. Query queue level: Configure all tasks in a query queue to run on Serverless resources.

  4. Automatic Serverless Computing: When enabled, the system automatically identifies large tasks and runs them on Serverless resources.

  5. If none of the preceding conditions apply, the SQL statement runs on the resources of the current instance.

While an SQL statement is running, you can also configure large queries to automatically rerun on Serverless resources. This reduces the load on production systems, reduces the frequency of out-of-memory (OOM) errors, and improves system stability.

Note

When an SQL statement runs on Serverless resources, those resources are dedicated to that SQL statement. No other SQL statements run concurrently.

Configure at the SQL level

This method is commonly used in the following scenarios:

  • One-time import or query tasks, such as refreshing historical data or rebuilding table schemas or properties.

  • Periodic offline import tasks, such as M+1, T+1, or H+1 offline data imports and exports. Add this configuration in your scheduling tasks.

  • Any other scenario that requires the flexible use of Serverless resources.

Run the following command to use Serverless Computing resources for an SQL statement. We recommend setting this at the session level.

-- Use Serverless Computing resources to run SQL. The default value is 'local', which means the SQL runs on resources of the current instance.
SET hg_computing_resource = 'serverless';

-- Reset the setting after submitting DML statements to prevent unnecessary SQL statements from using Serverless resources.
RESET hg_computing_resource;
Important
  • We do not recommend changing this setting at the database level.

  • You can run RESET hg_computing_resource to reset the parameter and prevent other SQL statements in the session from unnecessarily using Serverless resources.

Example:

-- Data preparation --
    -- Create the source table
CREATE TABLE source_tbl ( id int );
    -- Create the sink table
CREATE TABLE sink_tbl ( id int );
    -- Insert sample data into the source table
INSERT INTO source_tbl
SELECT * FROM generate_series(1, 99999999);

-- Run SQL with Serverless Computing resources --
    -- Enable the setting at the session level
SET hg_computing_resource = 'serverless';
    -- Run the SQL statement
INSERT INTO sink_tbl SELECT * FROM source_tbl;
    -- Reset the setting
RESET hg_computing_resource;

Configure at the user level

This method is commonly used in the following scenarios:

  • Daily use by high-privilege users, such as superusers.

  • High-priority data dashboards. You can configure the account associated with the dashboard's data source.

Run the following command to configure all SQL statements issued by a specific user or role to run on Serverless Computing resources by default.

Note

This configuration has a higher priority than database-level GUC settings but a lower priority than session-level GUC settings. For more information, see GUC parameters.

-- Make a user use Serverless Computing resources by default for SQL statements in a specific database
ALTER USER "<role_name>" IN DATABASE <db_name> SET hg_computing_resource = 'serverless';

-- Remove the setting
ALTER USER "<role_name>" IN DATABASE <db_name> RESET hg_computing_resource;

Configure at the query queue level

Hologres lets you configure a query queue so that all its SQL statements run on Serverless Computing resources. For more information about query queue configuration, see Query queues. Using this feature, you can use the classifier capability of query queues to route specific categories of SQL statements to Serverless resources. Examples include the following:

  • By query type: INSERT, SELECT, UPDATE, or DELETE.

  • By query engine: HQE, PQE, SQE, or HiveQE. For example, you can assign all non-direct-read MaxCompute external table tasks (SQE) to Serverless resources.

  • By SQL fingerprint: If a query pattern consumes many resources or poses stability risks, you can assign all matching SQL fingerprints to Serverless resources.

  • By storage mode: hot or cold. For example, you can assign all cold-storage queries to Serverless resources.

Run the following command to configure this feature:

  • General-purpose instances

    -- Run all queries in the target queue on Serverless resources
    CALL hg_set_query_queue_property('<query_queue_name>', 'computing_resource', 'serverless');
    
    -- (Optional) Set the priority when using Serverless resources for queries in the target queue. Valid values: 1 to 5. Default: 3
    CALL hg_set_query_queue_property('<query_queue_name>', 'query_priority_when_using_serverless_computing', '<priority>');
  • virtual warehouse instance

    -- Run all queries in the target queue on Serverless resources
    CALL hg_set_query_queue_property('<warehouse_name>', '<query_queue_name>', 'computing_resource', 'serverless');
    
    -- (Optional) Set the priority when using Serverless resources for queries in the target queue. Valid values: 1 to 5. Default: 3
    CALL hg_set_query_queue_property('<warehouse_name>', '<query_queue_name>', 'query_priority_when_using_serverless_computing', '<priority>');

Adaptive serverless computing

Hologres automatically identifies large tasks in the system and routes them to Serverless resources. For more information, see Automatic Serverless computing.

Automatic rerun of large jobs

If an SQL statement is already running on the resources of the current instance, you can further improve system stability by classifying queries that exceed a specified runtime or trigger an OOM error as large queries. These queries are then automatically rerun on Serverless resources. For more information, see Large query control.

Set priorities for Serverless Computing tasks

Hologres lets you set priorities for SQL statements that run on Serverless Computing resources. By limiting the maximum resource usage per SQL statement and using priority-based queuing, Hologres ensures stable and orderly execution of SQL statements on Serverless Computing resources.

For example:

Your instance uses 32 cores, and the maximum available Serverless Computing resources are 96 cores. SQL A is currently running on Serverless resources and uses 64 cores. In the Serverless task queue, SQL B requires 48 cores and has a priority of 5, while SQL C requires 32 cores and has a priority of 3. In this case, the system waits for SQL A to finish and then allocates 48 cores to run SQL B. The system does not use the remaining 32 cores to run SQL C, because SQL B has a higher priority.

  • Run the following command to set the priority for SQL statements on Serverless Computing resources.

    Priorities range from 1 to 5. The default is 3. A higher value indicates a higher priority and earlier resource allocation, regardless of the amount of resources requested.

    -- Configure at the session level
    SET hg_experimental_serverless_computing_query_priority = 5;
    -- Reset the setting
    RESET hg_experimental_serverless_computing_query_priority;
    
    -- Configure at the user level
    ALTER USER "<role_name>" IN DATABASE <db_name> SET hg_experimental_serverless_computing_query_priority = 5;
    -- Reset the setting
    ALTER USER "<role_name>" IN DATABASE <db_name> RESET hg_experimental_serverless_computing_query_priority;
  • Example

    -- Run SQL with Serverless Computing resources
    SET hg_computing_resource = 'serverless';
    
    -- Set the priority of this SQL to 5
    SET hg_experimental_serverless_computing_query_priority to 5;
    
    -- Run the SQL statement
    INSERT INTO sink_tbl SELECT * FROM source_tbl;
     
    -- Reset the settings
    RESET hg_computing_resource;
    RESET hg_experimental_serverless_computing_query_priority;

Verify Serverless Computing

Run the following command to view the execution plan for the SQL statement.

-- Use Serverless Computing resources to run SQL
SET hg_computing_resource = 'serverless';

-- Run the SQL statement
EXPLAIN INSERT INTO sink_tbl SELECT * FROM source_tbl;

-- Reset the setting
RESET hg_computing_resource;

The result is similar to the following. If the result contains Computing Resource: Serverless, it indicates that the SQL statement ran on Serverless Computing resources.

                                        QUERY PLAN                                        
------------------------------------------------------------------------------------------
 Gather  (cost=0.00..5.18 rows=100 width=4)
   ->  Insert  (cost=0.00..5.18 rows=100 width=4)
         ->  Redistribution  (cost=0.00..5.10 rows=100 width=4)
               ->  Local Gather  (cost=0.00..5.10 rows=100 width=4)
                     ->  Decode  (cost=0.00..5.10 rows=100 width=4)
                           ->  Seq Scan on source_tbl  (cost=0.00..5.00 rows=100 width=4)
 Computing Resource: Serverless
 Optimizer: HQO version 2.1.0
(8 rows)

You can also view active and historical tasks on Serverless resources. For more information, see Serverless Computing monitoring and O&M.