AnalyticDB for PostgreSQL V6.3.7.0 provides the query cache feature to speed up data retrieval by caching query results. This feature improves the performance of database queries in scenarios that require more reads than writes, especially those in which identical queries are frequently repeated.
Precautions
The query cache feature is available only in AnalyticDB for PostgreSQL V6.3.7.0 or later. For information about how to query and update the minor engine version of an AnalyticDB for PostgreSQL instance, see View the minor engine version and Update the minor engine version.
The following limits apply when you use the query cache feature in AnalyticDB for PostgreSQL:
- Query cache is supported only when the transaction isolation level is read committed (READ-COMMITTED).
- Query cache is supported only when the Grand Unified Configuration (GUC) parameters rds_uppercase_colname and gp_select_invisible are set to off.
- Cached data can be queried only when all tables in the query have the query cache feature enabled.
- Query cache is supported only when the frontend protocol version of libpq is 3.0 or later.
- If a query within a transaction block has been modified, its query results cannot be stored in the query cache.
- Query cache is not supported for temporary tables, views, materialized views, system tables, unlogged tables, external tables, or volatile or immutable functions.
- Query cache is not supported for queries on child partitioned tables.
- Query cache is not supported for queries when multiple coordinator nodes exist.
- Query cache is not supported if the result set exceeds 7.5 KB in size.
- Query cache is not supported when more than 32 tables are involved in a single query.
- Query cache is not supported if cursors are used in extended queries.
Enable query cache for an instance
By default, query cache is disabled because it is suitable only when a query has high temporal locality. To enable query cache for an instance, Submit a ticket.
Enable or disable query cache for a session
You can use the rds_session_use_query_cache parameter to enable or disable query cache for a session.
Execute the following statement to enable query cache for a session:
SET rds_session_use_query_cache = on;
Execute the following statement to disable query cache for a session:
SET rds_session_use_query_cache = off;
Enable or disable query cache for a table
You can use the querycache_enabled parameter to enable or disable query cache for a table.
For a new table, execute the following statement to enable query cache:
CREATE TABLE table_name (c1 int, c2 int) WITH (querycache_enabled=on);
For a table that did not have query cache enabled when the table was created, execute the following statement to enable query cache:
ALTER TABLE table_name SET (querycache_enabled=on);
For a table that no longer requires query cache, execute the following statement to disable query cache:
ALTER TABLE table_name SET (querycache_enabled=off);
Modify the validity period of query cache
When DDL or DML statements are being executed, query results stored in the query cache expire. This prevents the expired query results from being returned. However, AnalyticDB for PostgreSQL uses the multiversion concurrency control (MVCC) mechanism, and the query cache stores only the latest query results. As a result, expired query results are returned in scenarios such as those in which concurrent read and write operations exist.
By default, results stored in the query cache remain valid for 10 minutes. If an identical query is made after the query results have been cached for longer than 10 minutes, the query is performed normally and the cached results for the query are not returned.
To prevent expired query results from being returned, you can Submit a ticket to modify the validity period of query cache.
Performance evaluation
This section evaluates the performance of query cache in two load scenarios: online transaction processing (OLTP) and online analytical processing (OLAP).
OLTP
The following table describes the test results for point queries with indexes.
Scenario | Query cache is not used | Query cache is used |
---|---|---|
Cache hit rate: 0%
Statements used in the point query: 1 |
1,718 TPS |
|
Cache hit rate: 50%
Statements used in the point query: 2 |
807 TPS |
|
Cache hit rate: 100%
Statements used in the point query: 1 |
1,718 TPS | 11,219 TPS |
In OLTP scenarios, a normal query has a latency of about 10 ms. In the case that the cache hit rate is 100%, the query performance improves by about 6.5 times when query cache is used. Even if the cache hit rate is 0%, the query performance when query cache is used is not significantly lower than that when query cache is not used. The absolute amount of time required to complete a query with query cache enabled does not change significantly and does not exceed 20 ms when cache replacement exists.
OLAP
The following table describes the test results of queries on 10 GB of data.
Scenario | Query cache is not used | Query cache is used |
---|---|---|
10 GB TPC-H | 1,255 seconds | 522 seconds |
10 GB TPC-DS | 2,813 seconds | 1,956 seconds |
In OLAP scenarios, the query performance when query cache is used is significantly higher than that when query cache is not used. For example, in the TPC-H test, the performance of Q1 query improves by more than 1,000 times when the cache hit rate is not 0%. In the TPC-DS test, specific query results exceed the maximum size of 7.5 KB allowed for the query cache and are not cached. As a result, the test result does not present a significant performance improvement.