Amazon Aurora PostgreSQL 的扩展和模块

新扩展功能

1. 现在，您可以管理 SQL 函数中的所有查询，无论它们是否有参数。

2. 现在，您可以管理 PL/pgSQL 函数中的所有查询，无论它们是否有参数。

3. 现在，您可以管理通用计划中的查询，无论它们是否有参数。要了解有关通用计划与自定义计划的更多信息，请参阅 PostgreSQL 文档中的 PREPARE 语句。

4. 现在，您可以使用查询计划管理强制在查询计划中使用特定类型的聚合方法。

扩展改进

1. 您现在可以保存大小最多为 max_worker_processes 参数设置的 8KB 倍的计划。以前最大计划大小为 8KB。

2. 修复了未命名的预编译语句（如来自 JDBC 的语句）的错误。

3. 以前，当您尝试在 shared_preload_libraries 未加载 CREATE EXTENSION apg_plan_mgmt 的情况下执行此命令时，PostgreSQL 后端连接将被删除。现在，会显示一条错误消息，并且连接不会被删除。

4. apg_plan_mgmt.plans table 中 cardinality_error 的默认值为 NULL，但它在 apg_plan_mgmt.evolve_plan_baselines 函数执行期间可以设置为 -1。现在统一使用 NULL。

5. 现在将为引用临时表的查询保存计划。

6. 默认的最大计划数从 1000 增加到 10000。

7. 以下 pgss 参数已被弃用，因为应使用自动计划捕获模式而不是这些参数。

   • apg_plan_mgmt.pgss_min_calls

   • apg_plan_mgmt.pgss_min_mean_time_ms

   • apg_plan_mgmt.pgss_min_stddev_time_ms

   • apg_plan_mgmt.pgss_min_total_time_ms

新扩展功能

1. 新 update_plan_hash 参数可用于 validate_plans 函数。此参数更新不能准确重现的计划的 plan_hash。update_plan_hash 参数还允许您通过重新编写 SQL 来修复计划。然后，您可以将更好的计划注册为初始 SQL 的 Approved 计划。以下是使用 update_plan_hash 的示例。

   UPDATE apg_plan_mgmt.dba_plans SET plan_hash = new _plan_hash, plan_outline = good_plan_outline 
      WHERE sql_hash = bad_plan_sql_hash AND plan_hash = bad_plan_plan_hash;
   SELECT apg_plan_mgmt.validate_plans(bad_plan_sql_hash, bad_plan_plan_hash, 'update_plan_hash');
   SELECT apg_plan_mgmt.reload();

2. 提供了可以为指定的 SQL 语句生成 EXPLAIN 语句本文的新 get_explain_stmt 函数。它包括参数 sql_hash、plan_hash 和 explain_options。

   参数 explain_options 可以是任何有效的 EXPLAIN 选项的逗号分隔列表，如下所示。

   analyze,verbose,buffers,hashes,format json

   如果参数 explain_options 为 NULL 或是一个空字符串，get_explain_stmt 函数将生成简单的 EXPLAIN 语句。

   要为您的工作负载或工作负载的一部分创建 EXPLAIN 脚本，请使用 \a、\t 和 \o 选项将输出重定向到文件。例如，您可以使用 total_time 按 DESC 顺序排序的 PostgreSQL pg_stat_statements 视图为排名最高 (top-K) 的语句创建 EXPLAIN 脚本。

3. “收集并行查询”运算符的准确位置由成本花费确定，可能在一段时间内稍有改变。为防止这些差异使整个计划失效，查询计划管理现在计算同一个 plan_hash，即使“收集”运算符在计划树中移至不同位置。

4. 增加了对 pl/pgsql 函数内的非参数化语句的支持。

5. 当 apg_plan_mgmt 扩展在同一个集群中的多个数据库上安装，而两个或多个数据库被同时访问时，开销将减少。此外，此版本还修复了这个区域中可能造成计划未存储在共享内存中的错误。

扩展改进

1. 对 evolve_plan_baselines 函数的改进。

   1. evolve_plan_baselines 函数现在对计划中的所有节点计算 cardinality_error 指标。使用此指标，您可以识别基数估计错误较大且计划质量更不确定的任何计划。具有高 cardinality_error 值的长时间运行语句是进行查询优化的优先选择。

   2. evolve_plan_baselines 生成的报告现在包括 sql_hash、plan_hash 和计划 status。

   3. 您现在可以允许 evolve_plan_baselines 预先审批 Rejected 计划。

   4. evolve_plan_baselines 的 speedup_factor 的含义现在始终与基准计划相关。例如，1.1 值现在表示比基准计划快 10%。0.9 值表示比基准计划慢 10%。只使用运行时间（而不是总时间）进行对比。

   5. evolve_plan_baselines 函数现在通过新的方式预热缓存。具体方法是运行基准计划，然后再运行一次基准计划，然后运行候选计划一次。之前，evolve_plan_baselines 运行候选计划两次。这种方法显著增加了运行时间，尤其是会让候选计划变慢。但是，当候选计划使用基准计划中未使用的索引时，运行候选计划两次更可靠。

2. 查询计划管理不再保存引用系统表或视图、临时表或查询计划管理的自有表的计划。

3. 错误修复包括保存后立即缓存计划以及修复造成后端终止的错误。