All Products
Search
Document Center

Hologres:Manage queries

Last Updated:Sep 05, 2024

This topic describes how to diagnose issues related to queries and manage queries on a Hologres instance.

Overview

Hologres is compatible with PostgreSQL. You can view the execution information about queries on a Hologres instance by querying the hg_stat_activity (pg_stat_activity) view. This helps you analyze query execution information and diagnose the related issues. The query management feature involves the following operations:

Query the hg_stat_activity (pg_stat_activity) view

In Hologres V2.0 and later, the pg_stat_activity view is upgraded to the hg_stat_activity view. The hg_stat_activity view is an extension of the pg_stat_activity view. You can use the hg_stat_activity view to query more detailed runtime information about active SQL queries. For example, you can query the query ID, query engine, and resource consumption information. This helps you diagnose issues of active queries. You can execute the following statements to query the runtime information about SQL queries on a Hologres instance. You can also use other management tools that are compatible with PostgreSQL to query the runtime information about SQL queries based on the pg_stat_activity view.

-- Recommended syntax for Hologres V2.0 and later
SELECT *  FROM hg_stat_activity;

-- Syntax for Hologres V1.3 and earlier
SELECT *  FROM pg_stat_activity;

The following table describes fields in the hg_stat_activity view.

Field

Description

Supported by the hg_stat_activity view

Supported by the pg_stat_activity view

datid

The object identifier (OID) of the connected database at the Hologres backend.

Supported

Supported

datname

The name of the connected database at the Hologres backend.

Supported

Supported

pid

The ID of the process at the Hologres backend.

Supported

Supported

query_id

The ID of the current SQL statement. One SQL statement corresponds to one query_id.

Supported

Not supported

transaction_id

The ID of the transaction to which the current SQL statement belongs. A transaction may contain multiple SQL statements.

Supported

Not supported

usesysid

The system identifier of the user in the current active session.

Supported

Supported

usename

The username that is used to create the current connection.

Supported

Supported

application_name

The type of the application on the client.

Common application types:

  • Realtime Compute for Apache Flink (VVR version): {client_version}_ververica-connector-hologres.

  • Apache Flink: {client_version}_hologres-connector-flink.

  • DataWorks Data Integration that allows you to run batch synchronization tasks to read data from Hologres: datax_{jobId}.

  • DataWorks Data Integration that allows you to run batch synchronization tasks to write data to Hologres: {client_version}_datax_{jobId}.

  • DataWorks Data Integration that allows you to synchronize data from databases to Hologres in real time: {client_version}_streamx_{jobId}.

  • HoloWeb: holoweb.

  • MaxCompute that allows you to access Hologres by using external tables: MaxCompute.

  • Process of reading Hologres binary logs initiated by Holo Client: holo_client_replication. The query content is not displayed for tasks of this type.

For other applications, we recommend that you explicitly specify the application_name field in the connection string if the applications are connected to Hologres instances.

Supported

Supported

running_info

The status of an SQL query during the query execution process. The value is in the JSON format. This field contains the following subfields:

  • current_resource

    Serverless: This subfield is available only for queries that are executed by using serverless computing resources.

  • current_stage

    • stage_name<PARSE|OPTIMIZE|QUEUE|START|EXECUTE|FINISH>:

      • PARSE: The SQL query is being parsed.

        Note

        If an SQL query is in the PARSE state, the engine_type field is unavailable.

      • OPTIMIZE: An execution plan is being generated.

      • QUEUE: The SQL query is waiting for resources.

      • START: The SQL query starts to be executed.

      • EXECUTE: The SQL query is being executed.

      • FINISH: The SQL query is complete.

    • stage_duration_ms: the time elapsed from the start time of the current stage to the current time. Unit: milliseconds.

    • queue_time_ms: the queuing time in milliseconds. This subfield is available only for queries that are executed by using serverless computing resources.

    • serverless_allocated_cores: the number of compute units (CUs) of serverless computing resources that are requested. This subfield is available only for queries that are executed by using serverless computing resources.

    • serverless_allocated_workers: the number of workers of serverless computing resources that are requested. This subfield is available only for queries that are executed by using serverless computing resources.

  • engine_type: the execution engine that is used to process the current query.

    • {HQE}: the Hologres engine.

    • {HQE,PQE}: the PostgreSQL Query Engine (PQE).

    • {PG}: the system engine, which does not require much attention.

    • {SDK}: the fixed plan.

    • {HQE,SQE}: the engine that is used to process SQL queries on MaxCompute foreign tables when the direct read feature is disabled.

    • {HQE,HiveQE}: the engine that is used to process SQL queries on Object Storage Service (OSS) foreign tables when the direct read feature is disabled.

    • {HQE,SQE,HiveQE}: the engine that is used to process SQL queries on foreign tables when the direct read feature is disabled.

  • fe_id: the ID of the FE node.

  • warehouse_id: the ID of the virtual warehouse if a virtual warehouse instance is used.

Supported

Not supported

extend_info

Extended information such as the resource consumption during the SQL query execution. The value is in the JSON format. This field contains the following subfields:

  • total_cpu_max_time_ms: the cumulative duration of CPU consumption of the SQL query. Unit: milliseconds.

  • total_mem_max_bytes: the sum of the maximum memory value of each operator in the SQL query. Unit: bytes.

  • scanned_rows: the total number of rows that have been read by the SQL query.

  • affected_rows: the number of rows on which the data manipulation language (DML) statement is performed.

  • be_lock_waiters: the ID of the SQL query that is waiting for the current SQL query to release the lock. The current SQL query is holding the lock.

  • be_lock_converting_waiters: the ID of the SQL query that locks the current SQL query. The current SQL query is waiting for the SQL query to release the lock.

Note

The be_lock_waiters and be_lock_converting_waiters subfields are valid for the backend lock, not the frontend lock. For more information about how to troubleshoot lock issues, see Locks and lock troubleshooting.

Supported

Not supported

state

The status of the connection. Valid values:

  • active: The connection is active.

  • idle: The connection is idle.

  • idle in transaction: The connection is idle in a long-running transaction.

  • idle in transaction (Aborted): The connection is idle in a failed transaction.

  • \N: This value indicates that the process is not a user connection process. In most cases, this state is returned for a maintenance process at the system backend and can be ignored.

Supported

Supported

query_start

The time when the SQL query starts to be executed. If the value of state for the current SQL query is not active, the start time of the previous SQL query is used.

Supported

Supported

client_addr

The IP address of the client.

The displayed IP address may have been resolved and may not be the actual IP address of the client.

Supported

Supported

client_hostname

The hostname of the client.

Supported

Supported

client_port

The port number of the client.

Supported

Supported

backend_start

The start time of the backend process.

You do not need to pay much attention to this field of Hologres.

Supported

Supported

xact_start

The start time of the current transaction of the process.

  • If no transactions are active, an empty string is returned.

  • If the current query is in the first transaction of the process, the value of this field is the same as the value of the query_start field.

You do not need to pay much attention to this field of Hologres.

Supported

Supported

state_change

The time when the state of the connection was last changed.

You do not need to pay much attention to this field of Hologres.

Supported

Supported

wait_event_type

The type of the event for which the backend is waiting for. If the backend is waiting for no event, the value of this field is NULL. Valid values:

  • LWLock: The backend is waiting for a lightweight lock to be released.

  • Lock: The backend is waiting for a heavyweight lock to be released. The wait_event field indicates the type of the lock for which the backend is waiting.

  • BufferPin: The server process is waiting to access a data buffer, and no other process is checking the data buffer.

  • Activity: The server process is idle. This value is returned for a system process that is waiting to be run in the main processing loop.

  • Extension: The server process is in an extension module and is waiting to be run.

  • Client: The server process is waiting for a query from a user application. In addition, the server is expecting an activity that is unrelated to its internal processing to happen.

  • PC: The server process is waiting for an activity of another process on the server.

  • Timeout: The server process is waiting for a timeout.

  • IO: The server process is waiting for the completion of an I/O operation.

Supported

Supported

wait_event

The name of the event for which the backend is waiting. If the backend is waiting for no event, the value of this field is NULL.

Supported

Supported

backend_xid

The identifier of the top-level transaction at the Hologres backend.

Supported

Supported

backend_xmin

The xmin scope at the backend.

Supported

Supported

query

The last query that was run at the backend. If the value of the state field is active, the query that is being run is displayed. If the state field is set to a value other than active, the last query is displayed.

Supported

Supported

backend_type

The type of the backend. Supported types include autovacuum launcher, autovacuum worker, logical replication launcher, logical replication worker, parallel worker, background writer, client backend, checkpointer, startup, walreceiver, walsender, and walwriter. Backend execution components such as PQE are also supported.

Note

Take note of the client backend type. This type indicates the type of the application connection.

Supported

Supported

View active queries by using SQL statements

This section describes how to view active queries by using SQL statements.

  1. View the current active query and the execution stage and resource consumption of the current active query.

    Note

    Superusers of a Hologres instance can query the execution information about SQL statements that are submitted by all users of the Hologres instance. RAM users can query the execution information about SQL statements that are submitted only by themselves.

    -- Syntax for Hologres V2.0 and later
    SELECT query,state,query_id,transaction_id,running_info, extend_info 
    FROM hg_stat_activity 
    WHERE state = 'active' 
    AND     backend_type = 'client backend'
    AND     application_name != 'hologres'
    
    -- Syntax for Hologres V1.3 and earlier
    SELECT query,state,pid
    FROM pg_stat_activity 
    WHERE state = 'active' 
    AND     backend_type = 'client backend'
    AND     application_name != 'hologres'

    The following result is returned:

    -------------------------------------------------------------------------------
    query          | insert into test_hg_stat_activity select i, (i % 7) :: text, (i % 1007) from generate_series(1, 10000000)i;
    state          | active
    query_id       | 100713xxxx
    transaction_id | 100713xxxx
    running_info   | {"current_stage" : {"stage_duration_ms" :5994,
                                          "stage_name" :"EXECUTE" },
                       "engine_type" :"{HQE,PQE}",
                       "fe_id" :1,
                       "warehouse_id" :0 }
    extend_info    | {"affected_rows" :9510912,
                      "scanned_rows" :9527296 }
  2. View running queries that are sorted based on the CPU utilization.

    -- Syntax for Hologres V2.0 and later
    SELECT query,((extend_info::json)->'total_cpu_max_time_ms')::text::bigint AS cpu_cost,state,query_id,transaction_id 
    FROM hg_stat_activity WHERE state = 'active' ORDER BY 2 DESC;

    The following result is returned:

    ---------------------------------------------------------------------------------
    query          | select xxxxx
    cpu_cost       | 523461
    state          | active
    query_id       | 10053xxxx
    transaction_id | 10053xxxx
    ---------------------------------------------------------------------------------
    query          | insert xxxx
    cpu_cost       | 4817
    state          | active
    query_id       | 1008305xxx
    transaction_id | 1008305xxx
  3. View running queries that are sorted based on the memory usage.

    -- Syntax for Hologres V2.0 and later
    SELECT query,((extend_info::json)->'total_mem_max_bytes')::text::bigint AS mem_max_cost,state,query_id,transaction_id 
    FROM hg_stat_activity WHERE state = 'active' ORDER BY 2 DESC;

    The following result is returned:

    ---------------------------------------------------------------------------------
    query          | update xxxx;
    mem_max_cost   | 5727634542
    state          | active
    query_id       | 10053302784827629
    transaction_id | 10053302784827629
    ---------------------------------------------------------------------------------
    query          | select xxxx;
    mem_max_cost   | 19535640
    state          | active
    query_id       | 10083259096119559
    transaction_id | 10083259096119559
  4. View queries that are running on the current instance and take a long period of time.

    -- Syntax for Hologres V2.0 and later
    SELECT current_timestamp - query_start AS runtime, datname::text, usename, query, query_id
        FROM hg_stat_activity
        WHERE state != 'idle'
        AND backend_type = 'client backend'
        AND application_name != 'hologres'
        ORDER BY 1 DESC;
    
    -- Syntax for Hologres V1.3 and earlier
    SELECT current_timestamp - query_start AS runtime, datname::text, usename, query, pid
        FROM pg_stat_activity
        WHERE state != 'idle'
        AND backend_type = 'client backend'
        AND application_name != 'hologres'
        ORDER BY 1 DESC;

    The following result is returned:

    runtime          |  datname  | usename  | query_id    |      current_query
    -----------------+----------------+----------+------------------------------------
     00:00:24.258388 | holotest  | 123xxx   | 1267xx | UPDATE xxx;
     00:00:1.186394  | testdb    | 156xx    | 1783xx | select xxxx;

    The result indicates that the UPDATE query takes a long period of time and has been running for 24 seconds.

Use HoloWeb to view and manage active queries in a visualized way

This section describes how to use HoloWeb to view and manage active queries in a visualized way.

  1. Log on to the HoloWeb console. For more information, see Connect to HoloWeb and perform queries.

  2. In the top navigation bar, click Diagnostics and Optimization.

  3. In the left-side navigation pane, choose Management for Information about Active Queries > Active Query Tasks.

  4. On the Active Query Tasks page, click Query to view and manage the active queries on the current instance.

    The following table describes the parameters in the queried result.

    Parameter

    Description

    Query Start

    The time when the query starts to be executed.

    Runtime

    The period of time for which the query has been running.

    PID

    The process identifier (PID) of the query.

    Query

    The SQL statement that is executed to query data.

    State

    The status of the current connection. Valid values:

    • active: The connection is active.

    • idle: The connection is idle.

    • idle in transaction: The connection is idle in a long-running transaction.

    • idle in transaction (Aborted): The connection is idle in a failed transaction.

    • \N: This value indicates that the process is not a user connection process. In most cases, this state is returned for a maintenance process at the system backend and can be ignored.

    User Name

    The username that is used to create the current connection.

    Application

    The type of the application that initiates the query.

    Client Address

    The IP address of the client that sends the query request.

    If a query does not complete after a long period of time, you can click Cancel in the Operation column to cancel the query. You can also select multiple queries and click Batch Cancel to cancel multiple queries at a time.

  5. (Optional) Click Details in the Operation column of a query to view the details of the query.

    On the Details page, you can perform the following operations:

    • Copy: Copy the SQL statement that is executed for the query.

    • Format: Format the SQL statement that is executed for the query.

Troubleshoot lock issues

You can check whether an SQL statement of active queries acquires a lock or is waiting for a lock to be released. For more information, see Locks and lock troubleshooting.

Cancel queries

This section describes how to cancel queries that do not meet expectations by executing statements.

  • Cancel a single query:

    SELECT pg_cancel_backend(<pid>);
  • Cancel multiple queries at a time:

    SELECT pg_cancel_backend(pid)
            ,query
            ,datname
            ,usename
            ,application_name
            ,client_addr
            ,client_port
            ,backend_start
            ,state
    FROM    pg_stat_activity
    WHERE   length(query) > 0
    AND     pid != pg_backend_pid()
    AND     backend_type = 'client backend'
    AND     application_name != 'hologres'

Change the timeout period of active queries

Hologres allows you to change the timeout period of active queries by executing an SQL statement.

  • Syntax

    SET statement_timeout = <time>;
  • Parameters

    time: the timeout period of active queries. Valid values: 0 to 2147483647. Default unit: milliseconds. If you want to append a unit to the specified time value, enclose the value and the unit in single quotation marks ('). Otherwise, an error message is returned. The current default timeout period is eight hours. The settings of the timeout period take effect only for queries in the current session.

    Note

    The SET statement_timeout = <time> statement takes effect only when this statement is executed along with the SQL statements for which you want to change the timeout period.

  • Examples

    • Set the timeout period to 5,000 minutes. If you want to append a unit to the specified time value, enclose the value and the unit in single quotation marks (').

      SET statement_timeout = '5000min' ; 
      SELECT * FROM tablename;
    • Set the timeout period to 5,000 ms.

      SET statement_timeout = 5000 ; 
      SELECT * FROM tablename;

Change the timeout period of idle queries

The idle_in_transaction_session_timeout parameter specifies the timeout behavior after a transaction becomes idle. If you do not configure this parameter, a transaction that times out is not rolled back. As a result, deadlocks may occur during queries. Hologres allows you to change the timeout period of idle queries by executing an SQL statement.

  • Scenario

    To prevent deadlocks during queries, you must specify the timeout period of idle queries. For example, the following code starts a transaction but does not commit it by using the COMMIT statement. This results in a transaction leak that eventually causes a database-level deadlock and affects the normal use of the database.

    BEGIN; 
    SELECT * FROM t;

    You can resolve the issue by configuring the idle_in_transaction_session_timeout parameter to specify the timeout period. If a transaction has not been committed or rolled back after its connection is idle for a period longer than the timeout period specified by the idle_in_transaction_session_timeout parameter, Hologres automatically rolls back the transaction and closes the connection.

  • Syntax

    -- Change the timeout period for idle transactions in a session.
    SET idle_in_transaction_session_timeout=<time>;
    
    -- Change the timeout period for idle transactions in a database.
    ALTER database db_name SET idle_in_transaction_session_timeout=<time>;
  • Parameters

    time: the timeout period of active queries. Valid values: 0 to 2147483647. Default unit: milliseconds. If you want to append a unit to the specified time value, enclose the value and unit in single quotation marks (' '). Otherwise, an error is returned. In Hologres V0.10 and earlier, the default value of this parameter is 0. This means that idle transactions are not automatically rolled back. In Hologres V1.1, the default value of this parameter is changed to 600000, which indicates 10 minutes. If a transaction is idle for more than 10 minutes, the transaction is rolled back.

    Note

    If the timeout period is shorter than required, transactions that are in use may be rolled back by mistake. We recommend that you set an appropriate timeout period for idle transactions.

  • Examples

    Set the timeout period to 300,000 ms.

    -- Change the timeout period for idle transactions in a session.
    SET idle_in_transaction_session_timeout=300000;
    
    -- Change the timeout period for idle transactions in a database.
    ALTER database db_name SET idle_in_transaction_session_timeout=300000;

Query slow query logs

In Hologres V0.10 and later, you can query slow query logs. For more information, see Query and analyze slow query logs.

FAQ

  • Problem description

    After SQL statements are executed, the following error message is returned: ERROR: canceling statement due to statement timeout.

  • Possible causes and solutions

    • Cause 1: The timeout period is configured for a Hologres instance or a client in the following scenarios:

      • If you create an API in DataService Studio, the timeout period for DataService Studio is 10s and cannot be modified. We recommend that you optimize SQL statements to reduce the execution time.

      • If you execute a query by using a Hologres SQL node of HoloWeb or DataWorks, the timeout period for executing the query is 1 hour and cannot be modified. We recommend that you optimize SQL statements to reduce the execution time.

      • If a timeout period is configured for a Hologres instance, you can execute the following SQL statement to query the timeout period. If the error is caused by inappropriate setting of the timeout period, modify the timeout period.

        SHOW statement_timeout;
      • If the timeout period is configured for a client or an application, you must check the settings of the client or the application. If the error is caused by the timeout period specified by the client, you can specify an appropriate timeout period based on your business requirements.

    • Cause 2: The DROP or TRUNCATE statement is executed on a table when DML statements are executed.

      The execution of TRUNCATE is equal to the execution of both DROP and CREATE. When you execute the TRUNCATE statement, a table is dropped and created again. When DML statements are executed, row locks or table locks are acquired. For more information about locks, see Locks and lock troubleshooting. If the DROP or TRUNCATE statement is executed on the table at the same time, the DROP or TRUNCATE statement acquires the locks. In this case, the system cancels the DML statements. As a result, the statement timeout error message is returned.

      Solution: Use slow query logs to check whether the DROP or TRUNCATE statement is executed on the table when DML statements are executed. The following sample code provides an example. We recommend that you do not execute the DROP or TRUNCATE statement when DML statements are executed.

      -- Query records of the DROP and TRUNCATE statements that are executed on a table in the previous day.
      SELECT * FROM hologres.hg_query_log 
      WHERE command_tag IN ('DROP TABLE','TRUNCATE TABLE') 
      AND query LIKE '%xxx%' AND query_start >= now() - interval '1 day';