tencent cloud

TencentDB for PostgreSQL

DocumentationTencentDB for PostgreSQLAI CapabilitiesAI for DB Intelligent OpsIntelligent Index Recommendation (tencentdb_index_advisor)

Intelligent Index Recommendation (tencentdb_index_advisor)

Download
Focus Mode
Font Size
Last updated: 2026-06-08 10:32:13
TencentDB for PostgreSQL provides the intelligent index recommendation extension. This document introduces the description and practices for the intelligent index recommendation (tencentdb_index_advisor) extension.

Overview

tencentdb_index_advisor is an intelligent index recommendation extension provided by TencentDB for PostgreSQL. It can automatically analyze single SQL statements or batch workloads and recommend optimal index schemes, allowing you to evaluate the effectiveness without physically creating the indexes.
Core Value:
Intelligent Analysis: Automatically identifies candidate index columns in conditions such as WHERE, JOIN, ORDER BY, and GROUP BY.
Zero-Cost Evaluation: Evaluates the effectiveness through Hypothetical Indexes without incurring any disk overhead.
Multi-Scenario Coverage: Supports index recommendations for various SQL statements, including SELECT, UPDATE, and DELETE.
Batch Optimization: Supports workload-level index recommendations by analyzing multiple SQL statements at once to find the globally optimal solution.
Secure and Reliable: The read-only analysis does not modify data. Recommended results are manually created after they are reviewed by a DBA.
Typical Scenarios:
Plan indexes for core queries before launching new services.
Troubleshoot slow queries to quickly identify missing indexes.
Perform database performance inspections and batch analyze the index optimization potential of TOP SQL.
Evaluate whether covering indexes are needed for existing queries during index tuning.

Environment Requirements

Project
Requirement
TencentDB for PostgreSQL version
15.x or later
Extension version
tencentdb_index_advisor v1.0
Dependent extension
hypopg v1.4.1 (automatically installed)
Execution permission
Members of the pg_tencentdb_superuser role
Execution environment
Executable only on the Primary (Primary).

Installation and Verification

Installing an Extension

-- Install the hypopg extension (if it is not already installed).
CREATE EXTENSION IF NOT EXISTS hypopg;

-- Install the index recommendation extension.
CREATE EXTENSION IF NOT EXISTS tencentdb_index_advisor;

Verifying the Installation

SELECT extname, extversion FROM pg_extension
WHERE extname IN ('hypopg', 'tencentdb_index_advisor')
ORDER BY extname;
Expected output:
extname
extversion
hypopg
1.4.1
tencentdb_index_advisor
1.0

Function Description

Function Signature

tencentdb_index_advise(query_string text)
RETURNS TABLE (
schema_name text,
table_name text,
am_name text,
index_size bigint,
index_def text
)
Parameters:
Parameter
Type
Description
query_string
text
The SQL statement(s) to be analyzed, supporting single or multiple statements (separated by semicolons).

Output Fields

Field
Type
Description
schema_name
text
The name of the Schema where the recommended index resides
table_name
text
The name of the table where the recommended index resides
am_name
text
Index access method (typically btree)
index_size
bigint
Estimated index size (in bytes)
index_def
text
The complete CREATE INDEX statement, which can be executed directly

GUC Configuration Parameters

Parameter Name
Type
Default Value
Description
tencentdb_index_advisor.enable_covering_index
bool
on
Whether to enable covering index recommendations. After enabled, recommended indexes include the extra columns required by queries, supporting index-only scan (Index-Only Scan).
tencentdb_index_advisor.show_benefits
bool
on
Whether to display the estimated cost benefit of recommended indexes
tencentdb_index_advisor.try_variation_timeout
int
10 (seconds)
Timeout for the variation optimization phase. Setting it to 0 skips this phase and speeds up recommendation.
tencentdb_index_advisor.enable_workload_compression
bool
off
Whether to enable workload compression. After enabled, SQL statements with similar patterns are deduplicated to reduce processing time.
tencentdb_index_advisor.max_index_recommend
int
8
Maximum number of indexes recommended per session
Parameter Configuration Example:
-- Disable covering index recommendations (to reduce index size).
SET tencentdb_index_advisor.enable_covering_index = off;

-- Limit the maximum number of recommended indexes to 3.
SET tencentdb_index_advisor.max_index_recommend = 3;

-- Skip the mutation optimization phase (to speed up recommendations).
SET tencentdb_index_advisor.try_variation_timeout = 0;

-- Enable workload compression during batch analysis.
SET tencentdb_index_advisor.enable_workload_compression = on;

Common Query Scenarios

Scenario 1: Index Recommendation for a Single Slow Query

When an SQL query runs slowly, directly obtain recommended indexes:
-- Recommend indexes for slow queries.
SELECT schema_name, table_name, am_name,
pg_size_pretty(index_size) AS est_size,
index_def
FROM tencentdb_index_advise(
'SELECT * FROM orders WHERE customer_id = 123 AND status = ''shipped'' AND order_date > ''2025-01-01'''
);
Output example:
schema_name
table_name
am_name
est_size
index_def
public
orders
btree
2360 kB
CREATE INDEX ON public.orders USING btree (customer_id,status)
Note:
It is recommended to create a composite index on (customer_id, status) on the orders table. Columns used in equality conditions (customer_id, status) should be placed first, while the column used in range conditions (order_date) should be placed as a secondary component.

Scenario 2: Cross-Table Index Recommendation for JOIN Queries

SELECT schema_name, table_name, am_name,
pg_size_pretty(index_size) AS est_size,
index_def
FROM tencentdb_index_advise(
'SELECT o.id, c.name, o.amount
FROM orders o JOIN customers c ON o.customer_id = c.id
WHERE c.city = ''Beijing'' AND o.status = ''delivered'''
);
Output example:
schema_name
table_name
am_name
est_size
index_def
public
orders
btree
4528 KB
CREATE INDEX ON public.orders USING btree (status,customer_id,id,amount)
public
customers
btree
312 KB
CREATE INDEX ON public.customers USING btree (city)
Note:
It is recommended to create indexes for the two tables separately. For the orders table, the index should use the columns from the JOIN and WHERE conditions as keys. For the customers table, the index should cover the filter criteria city.

Scenario 3: Batch Analysis of TOP SQL (Workload Recommendation)

Analyze multiple slow queries together to find the globally optimal index combination:
-- Analyze multiple business SQL statements simultaneously.
SELECT schema_name, table_name,
pg_size_pretty(index_size) AS est_size,
index_def
FROM tencentdb_index_advise('
SELECT * FROM orders WHERE customer_id = 100;
SELECT * FROM orders WHERE status = ''pending'' AND region = ''east'';
SELECT * FROM products WHERE category = ''electronics'' AND price < 200;
SELECT o.id, c.name FROM orders o JOIN customers c ON o.customer_id = c.id WHERE c.city = ''Beijing'';
');
Output example:
schema_name
table_name
est_size
index_def
public
orders
8350 KB
CREATE INDEX ON public.orders USING btree (customer_id,...)
public
orders
8350 KB
CREATE INDEX ON public.orders USING btree (region,status,...)
public
products
1416 KB
CREATE INDEX ON public.products USING btree (category,price,...)
public
customers
312 KB
CREATE INDEX ON public.customers USING btree (city,...)
Note:
Workload recommendations comprehensively consider the requirements of all SQL statements to find the index combination with the greatest benefit. This approach is more reasonable than analyzing individual statements.

Scenario 4: Covered Index Comparison

-- Enable covering index recommendations.
SET tencentdb_index_advisor.enable_covering_index = on;
SELECT index_def FROM tencentdb_index_advise(
'SELECT customer_id, amount FROM orders WHERE status = ''shipped'' AND region = ''east'''
);
-- Result: CREATE INDEX ON public.orders USING btree (region, status, customer_id, amount)

-- Disable covering index recommendations.
SET tencentdb_index_advisor.enable_covering_index = off;
SELECT index_def FROM tencentdb_index_advise(
'SELECT customer_id, amount FROM orders WHERE status = ''shipped'' AND region = ''east'''
);
-- Result: CREATE INDEX ON public.orders USING btree (region, status)
Note:
The covering index includes the customer_id and amount columns required by the query, enabling Index-Only scans and avoiding table lookups. However, the index has a larger size, so you need to weigh this against the actual query frequency.

Scenario 5: Index Optimization for UPDATE/DELETE Statements

-- Index Recommendations for UPDATE Statements
SELECT index_def FROM tencentdb_index_advise(
'UPDATE orders SET amount = 0 WHERE customer_id = 123 AND status = ''cancelled'''
);
-- Result: CREATE INDEX ON public.orders USING btree (customer_id, status)

-- Index Recommendations for DELETE Statements
SELECT index_def FROM tencentdb_index_advise(
'DELETE FROM orders WHERE customer_id = 999 AND order_date < ''2025-01-01'''
);
-- Result: CREATE INDEX ON public.orders USING btree (customer_id, order_date)
Note:
The WHERE clauses in UPDATE and DELETE statements can also benefit from indexes, reducing the number of rows that need to be scanned.

Index Recommendation Algorithm Principles

Note:

Input the SQL statement.
Step 1: Query Parsing
└── Parse clauses such as WHERE/JOIN/GROUP BY/ORDER BY.
Step 2: Candidate Index Column Generation
└── Identify candidate columns by priority:
EQUALITY (equality) > RANGE (range) > JOIN (join)
> GROUP_ORDER (sorting/grouping) > COVERING (covering)
Step 3: Hypothetical Index Creation
└── Create a hypothetical index using hypopg (does not occupy disk space).
Step 4: Cost Evaluation
└── Use the PostgreSQL optimizer to evaluate the execution cost difference with and without an index.
Step 5: Greedy Selection + Mutation Optimization
└── Use a greedy algorithm to select the index combination with the greatest benefit.
During the mutation phase, different combinations are attempted to find a better solution.
Step 6: Output Recommendations
└── Return the CREATE INDEX statement and the estimated index size.

Note:

Priority
Type
Scenario
Description
1 (Highest)
EQUALITY
WHERE col = value
Equality matching with the best selectivity
2
RANGE
WHERE col > value
Range query
3
JOIN
ON a.col = b.col
Join condition
4
GROUP_ORDER
GROUP BY col / ORDER BY col
Sorting and Grouping
5 (Lowest)
COVERING
SELECT col
Covering query columns (to avoid table lookups)

Ops Practical Guide

Note:

Step 1: Extract the TOP slow queries from pg_stat_statements.
└── SELECT query FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
Step 2: Batch Input to Index Recommendation
└── SELECT * FROM tencentdb_index_advise('slow_query1; slow_query2; ...');
Step 3: Evaluate Recommended Indexes
├── Check the estimated index size to assess its impact on disk space.
├── Use EXPLAIN to verify changes in the query plan.
└── Confirm that there are no duplicate/redundant indexes.
Step 4: Create Indexes During Off-Peak Hours
└── CREATE INDEX CONCURRENTLY ... (Creates the index online without locking the table.)
Step 5: Verify the Results
└── Compare query execution times and execution plans before and after creation.

Note:

Before formally creating an index, you can first use EXPLAIN to verify its effectiveness:
-- Step 1: View the current execution plan and cost.
EXPLAIN SELECT * FROM orders WHERE customer_id = 123 AND status = 'shipped';
-- Result: Seq Scan, cost=1218.0

-- Step 2: Obtain the Recommended Index
SELECT index_def FROM tencentdb_index_advise(
'SELECT * FROM orders WHERE customer_id = 123 AND status = ''shipped'''
);
-- Result: CREATE INDEX ON public.orders USING btree (customer_id, status)

-- Step 3: Create the index (Use CONCURRENTLY in production environments.)
CREATE INDEX CONCURRENTLY idx_orders_cust_status
ON orders USING btree (customer_id, status);

-- Step 4: Verify the Optimization Results
EXPLAIN SELECT * FROM orders WHERE customer_id = 123 AND status = 'shipped';
-- Result: Index Scan, cost=8.31 (99.3% performance improvement)

Parameter Tuning Recommendations

Scenario
Recommended Parameter Setting
Description
Quick Recommendation
try_variation_timeout = 0
Skips variation optimization, suitable for emergency troubleshooting.
Deep Optimization
try_variation_timeout = 30
Performing more thorough combinatorial searches, suitable for important queries.
Controlling Index Quantity
max_index_recommend = 3
Limits the number of recommendations to avoid excessive indexes.
Reducing Index Size
enable_covering_index = off
Does not recommend covering columns, resulting in smaller indexes.
Batch Analysis
enable_workload_compression = on
Deduplicates similar SQL statements to accelerate analysis speed.

Definitions

Term
Description
Hypothetical Index
A virtual index created through the hypopg extension, which resides only in session memory, does not occupy disk space, but can be recognized and used by the PostgreSQL optimizer for execution plan evaluation.
Covering Index (Covering Index)
An index that contains all columns required by a query, supports index-only scan (Index-Only Scan), and avoids reading data pages by returning to the table.
Variation Phase
The optimization phase that, after the greedy algorithm yields a preliminary result, seeks a better solution by trying different index column combinations.
Workload Compression
Performs pattern matching and deduplication on input SQL statements, preserving query diversity while reducing analysis time.
RMGR
Resource Manager, a type of resource manager.
Index-Only Scan
Index-only scan, where a query can obtain all required data by reading only the index, without needing to access heap pages by returning to the table.
CONCURRENTLY
PostgreSQL's online index creation mode, which does not block DML operations on the table.

Must-Knows

Available only on the primary database: Index recommendations cannot be executed on standby databases.
Dependency on hypopg: The hypopg extension must be installed first.
Permission Requirement: Membership in the pg_tencentdb_superuser role is required.
Recommendation ≠ Execution: Recommended results must be manually created after being reviewed by a DBA. The index_def field can be directly executed as DDL.
CONCURRENTLY Creation: When an index is created in a production environment, it is recommended to use CREATE INDEX CONCURRENTLY to avoid locking the table.
More indexes are not always better: Excessive indexes increase write overhead and storage costs. It is recommended to comprehensively evaluate based on query frequency and benefit.
Regular Maintenance: After business changes, it is recommended to rerun index recommendations and clean up indexes that are no longer needed.
Multiple SQL Analysis: Workload recommendations are more accurate than analyzing individual statements and can identify the globally optimal index combination.
LIKE Queries: For prefix matching (LIKE 'prefix%'), the extension recommends indexes with text_pattern_ops. Suffix matching (LIKE '%suffix') cannot use B-tree indexes.

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback