Extension versions for Amazon Aurora PostgreSQL

You can now manage all queries inside SQL functions, whether they have parameters or not.

You can now manage all queries inside PL/pgSQL functions, whether they have parameters or not.

You can now manage queries in generic plans, whether they have parameters or not. To learn more about generic plans versus custom plans, see the PREPARE statement in the PostgreSQL documentation.

You can now use query plan management to enforce the use of specific types of aggregate methods in query plans.

You can now save plans with a size up to 8KB times the setting of the max_worker_processes parameter. Previously the maximum plan size was 8KB.

Fixed bugs for unnamed prepared statements such as those from JDBC.

Previously, when you tried to do CREATE EXTENSION apg_plan_mgmt when it is not loaded in the shared_preload_libraries, the PostgreSQL backend connection was dropped. Now, an error message prints and the connection is not dropped.

The default value of the cardinality_error in the apg_plan_mgmt.plans table is NULL, but it can be set to -1 during the apg_plan_mgmt.evolve_plan_baselines function. NULL is now used consistently.

Plans are now saved for queries that refer to temporary tables.

The default maximum number of plans is increased from 1000 to 10000.

The following pgss parameters are deprecated because the automatic plan capture mode should be used instead of those parameters.

The validate_plans function has a new action value called update_plan_hash. This action updates the plan_hash ID for plans that can't be reproduced exactly. The update_plan_hash value also allows you to fix a plan by rewriting the SQL. You can then register the good plan as an Approved plan for the original SQL. Following is an example of using the update_plan_hash action.

UPDATE apg_plan_mgmt.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();

A new get_explain_stmt function is available that generates the text of an EXPLAIN statement for the specified SQL statement. It includes the parameters sql_hash, plan_hash and explain_options.

The parameter explain_options can be any comma-separated list of valid EXPLAIN options, as shown following.

analyze,verbose,buffers,hashes,format json

If the parameter explain_options is NULL or an empty string, the get_explain_stmt function generates a simple EXPLAIN statement.

To create an EXPLAIN script for your workload or a portion of it, use the \a , \t, and \o options to redirect the output to a file. For example, you can create an EXPLAIN script for the top-ranked (top-K) statements by using the PostgreSQL pg_stat_statements view sorted by total_time in DESC order.

The precise location of the Gather parallel query operator is determined by costing, and may change slightly over time. To prevent these differences from invalidating the entire plan, query plan management now computes the same plan_hash even if the Gather operators move to different places in the plan tree.

Support is added for nonparameterized statements inside pl/pgsql functions.

Overhead is reduced when the apg_plan_mgmt extension is installed on multiple databases in the same cluster while two or more databases are being accessed concurrently. Also, this release fixed a bug in this area that caused plans to not be stored in shared memory.

Improvements to the evolve_plan_baselines function.

Query plan management no longer saves plans that refer to system tables or views, temporary tables, or the query plan management's own tables.

Bug fixes include caching a plan immediately when saved and fixing a bug that caused the back end to terminate.