Hologres:Run read and write tasks with serverless computing

Session-level configuration

Set hg_computing_resource at the session level to route all SQL in the current connection to serverless resources. Reset the parameter immediately after your task to avoid unintentionally routing subsequent queries.

Use this method for:

• One-time tasks such as historical data refreshes or table schema modifications (REBUILD).

• Periodic offline import tasks (M+1, T+1, or H+1). Add the SET and RESET commands to your scheduled task.

• Any scenario where you need flexible, per-session control over resource routing.

-- Route the current session to Serverless Computing resources.
-- Default value is local (uses instance resources).
SET hg_computing_resource = 'serverless';

-- Run your DML statement.
INSERT INTO sink_tbl SELECT * FROM source_tbl;

-- Reset after the task. This prevents subsequent SQL from using serverless resources unintentionally.
RESET hg_computing_resource;

Full example:

-- Data preparation
CREATE TABLE source_tbl (id int);
CREATE TABLE sink_tbl (id int);
INSERT INTO source_tbl SELECT * FROM generate_series(1, 99999999);

-- Route to serverless and run the task
SET hg_computing_resource = 'serverless';
INSERT INTO sink_tbl SELECT * FROM source_tbl;
RESET hg_computing_resource;

User-level configuration

Configure all SQL initiated by a specific user or role to run on serverless resources by default. This method takes priority over database-level GUC configuration but yields to session-level configuration. For details, see GUC parameters.

Use this method for:

• Superusers or other high-privilege users whose tasks should always use serverless resources.

• Data source accounts that power high-priority dashboards.

-- Route all SQL from a specific user in a database to serverless resources.
ALTER USER "<role_name>" IN DATABASE <db_name> SET hg_computing_resource = 'serverless';

-- Revert the configuration.
ALTER USER "<role_name>" IN DATABASE <db_name> RESET hg_computing_resource;

Query Queue-level configuration

Configure an entire Query Queue to route all its SQL to serverless resources. This lets you use Query Queue classifiers to target specific SQL by type, engine, SQL fingerprint, or storage mode. For information on configuring a Query Queue, see Query Queue.

Examples of what you can target:

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

• By query engine: HQE, PQE, SQE, HiveQE. For example, route all SQE tasks (non-direct-read MaxCompute external table queries) to serverless resources.

• By SQL fingerprint: If a specific query pattern poses a stability risk, configure its SQL fingerprint to always run on serverless resources.

• By storage mode: Route all cold storage queries to serverless resources.

General-purpose instance:

-- Route all queries in the target queue to serverless resources.
CALL hg_set_query_queue_property('<query_queue_name>', 'computing_resource', 'serverless');

-- (Optional) Set the query priority for this queue when using serverless resources.
-- Valid values: 1-5. Default: 3.
CALL hg_set_query_queue_property('<query_queue_name>', 'query_priority_when_using_serverless_computing', '<priority>');

Virtual warehouse instance:

-- Route all queries in the target queue to serverless resources.
CALL hg_set_query_queue_property('<warehouse_name>', '<query_queue_name>', 'computing_resource', 'serverless');

-- (Optional) Set the query priority for this queue when using serverless resources.
-- Valid values: 1-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 can automatically identify large tasks and route them to serverless resources, without any manual configuration per query. For details, see Adaptive Serverless Computing.

Automatic retry for large tasks

Define thresholds for "large queries" — such as queries that run beyond a specified duration or cause an OOM error. Hologres then automatically retries those queries on serverless resources. This reduces the load on production services, lowers OOM frequency, and improves system stability. For details, see Large query control.