本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
Amazon Aurora PostgreSQL 的扩展和模块
Aurora PostgreSQL apg_plan_mgmt 扩展
Aurora PostgreSQL apg_plan_mgmt 扩展版本 2.0
您可以将 apg_plan_mgmt
扩展与查询计划管理结合使用。有关如何安装、升级和使用 apg_plan_mgmt
扩展的更多消息,请参阅 管理 Aurora PostgreSQL 的查询执行计划。
版本 2.0 的 apg_plan_mgmt
扩展更改包括以下内容:
新扩展功能
-
现在,您可以管理 SQL 函数中的所有查询,无论它们是否有参数。
-
现在,您可以管理 PL/pgSQL 函数中的所有查询,无论它们是否有参数。
-
现在,您可以管理通用计划中的查询,无论它们是否有参数。要了解有关通用计划与自定义计划的更多信息,请参阅 PostgreSQL 文档
中的 PREPARE
语句。 -
现在,您可以使用查询计划管理强制在查询计划中使用特定类型的聚合方法。
扩展改进
-
您现在可以保存大小最多为
max_worker_processes
参数设置的 8KB 倍的计划。以前最大计划大小为 8KB。 -
修复了未命名的预编译语句(如来自 JDBC 的语句)的错误。
-
以前,当您尝试在
shared_preload_libraries
未加载CREATE EXTENSION apg_plan_mgmt
的情况下执行此命令时,PostgreSQL 后端连接将被删除。现在,会显示一条错误消息,并且连接不会被删除。 -
apg_plan_mgmt.plans table
中cardinality_error
的默认值为 NULL,但它在apg_plan_mgmt.evolve_plan_baselines
函数执行期间可以设置为 -1。现在统一使用 NULL。 -
现在将为引用临时表的查询保存计划。
-
默认的最大计划数从 1000 增加到 10000。
-
以下 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
-
Aurora PostgreSQL apg_plan_mgmt 扩展版本 1.0.1
版本 1.0.1 的 apg_plan_mgmt
扩展更改包括以下内容:
新扩展功能
-
新
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(); -
提供了可以为指定的 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
顺序排序的 PostgreSQLpg_stat_statements
视图为排名最高 (top-K) 的语句创建EXPLAIN
脚本。 -
“收集并行查询”运算符的准确位置由成本花费确定,可能在一段时间内稍有改变。为防止这些差异使整个计划失效,查询计划管理现在计算同一个
plan_hash
,即使“收集”运算符在计划树中移至不同位置。 -
增加了对 pl/pgsql 函数内的非参数化语句的支持。
-
当
apg_plan_mgmt
扩展在同一个集群中的多个数据库上安装,而两个或多个数据库被同时访问时,开销将减少。此外,此版本还修复了这个区域中可能造成计划未存储在共享内存中的错误。
扩展改进
-
对
evolve_plan_baselines
函数的改进。-
evolve_plan_baselines
函数现在对计划中的所有节点计算cardinality_error
指标。使用此指标,您可以识别基数估计错误较大且计划质量更不确定的任何计划。具有高cardinality_error
值的长时间运行语句是进行查询优化的优先选择。 -
evolve_plan_baselines
生成的报告现在包括sql_hash
、plan_hash
和计划status
。 -
您现在可以允许
evolve_plan_baselines
预先审批Rejected
计划。 -
evolve_plan_baselines
的speedup_factor
的含义现在始终与基准计划相关。例如,1.1 值现在表示比基准计划快 10%。0.9 值表示比基准计划慢 10%。只使用运行时间(而不是总时间)进行对比。 -
evolve_plan_baselines
函数现在通过新的方式预热缓存。具体方法是运行基准计划,然后再运行一次基准计划,然后运行候选计划一次。之前,evolve_plan_baselines
运行候选计划两次。这种方法显著增加了运行时间,尤其是会让候选计划变慢。但是,当候选计划使用基准计划中未使用的索引时,运行候选计划两次更可靠。
-
-
查询计划管理不再保存引用系统表或视图、临时表或查询计划管理的自有表的计划。
-
错误修复包括保存后立即缓存计划以及修复造成后端终止的错误。