7.0版Query Cache

类似于AnalyticDB PostgreSQL 6.0版中的查询缓存，该特性可以缓存查询结果，且在出现重复查询时可以迅速地返回查询结果。因此该特性适用于读多写少的场景，特别是重复查询较多的场景。在此类场景中使用该特性可以有效地提升查询性能。

版本限制

内核版本为v7.0.6.9及以上的AnalyticDB PostgreSQL 7.0版实例。

使用限制

以下场景不支持Query Cache。

• 直接访问分区子表。

• libpq前端协议版本小于3.0。

• 单次查询中涉及的表超过128张。

• Extended Query中使用了游标。

• 事务隔离级别设置为READ-UNCOMMITTED或SERIALIZABLE。

• 未指定表参数querycache_enabled=on。

• GUC参数gp_select_invisible参数值设置为on。

• 如果在事务块内执行查询之前有过修改操作，查询结果无法缓存在Query Cache中。

• 临时表、视图、物化视图、系统表、非日志表、外表、volatile/immutable函数不支持Query Cache。

• 结果集过大时不支持使用Query Cache。查询能被缓存的最大结果集大小默认为1 MB，如需修改此约束，请提交工单（调整后需要重启实例）。

当以上情况均未出现时，AnalyticDB PostgreSQL 7.0版将自动缓存查询结果。若未来出现同样的查询时，则直接使用本次缓存结果。

表级开启或关闭Query Cache

您可以使用querycache_enabled参数在表级别开启或关闭Query Cache功能。

对于新建表，可以使用如下语句开启Query Cache。

CREATE TABLE table_name (c1 int, c2 int) WITH (querycache_enabled=on);

对于建表时未开启Query Cache的表，可以使用如下语句开启Query Cache。

ALTER TABLE table_name SET (querycache_enabled=on);

对于不再需要使用Query Cache的表，可以使用如下语句关闭Query Cache。

ALTER TABLE table_name SET (querycache_enabled=off);

Query Cache失效

为了保证Query Cache查询结果的正确性，当实例中的表涉及DDL或DML修改操作时，对应的表的查询结果缓存将失效。

由于云原生数据仓库 AnalyticDB PostgreSQL 版使用MVCC机制，而Query Cache只缓存最新的查询结果，因此可能会出现缓存未及时更新，从而导致查询结果过期的情况。典型的场景是同一张表读写事务并发。

CREATE TABLE test1 (c1 int, c2 int) WITH (querycache_enabled=on);
1: BEGIN；
1: SELECT * FROM test1;
2: BEGIN;
2: INSERT INTO test1 values (3, 4);
2: COMMIT;
1: COMMIT;
-- 这行执行结果仍是空，而查不出（3,4）, 因为引用了上次的缓存
1: SELECT * FROM test1;

针对此情况，Query Cache提供了参数adbpg_querycache_item_valid_duration。该参数控制查询结果缓存的有效生命周期（默认值为10分钟）。如果某查询结果缓存时间超过了该生命周期，当同样查询进来时，不再引用该查询结果，而是重新执行该查询。您可以根据实际情况，关闭该表的Query Cache（querycache_enabled=off），或是设置adbpg_querycache_item_valid_duration值。

性能评估

AnalyticDB PostgreSQL 7.0版中的Query Cache在TP负载性能方面未表现出显著提升，也不会对性能造成负面影响。AP负载方面，分别使用10 GB的TPC-H和TPC-DS负载进行了评估，其结果如下。

从结果来看，无论TPC-H还是TPC-DS，查询性能都有显著提升。对于TPC-H，查询命中缓存时，Q1（耗时10毫秒）有超过1000倍的性能提升。理论上，如果查询命中Query Cache，执行时间基本在1秒之内。而实际在使用Query Cache时， TPC-H和TPC-DS总耗时在10秒左右，是因为部分查询结果超过了单次查询能够缓存在Query Cache中的最大值1 MB，因此这些查询的查询结果没有被缓存。