I put together patches to do as is being proposed. v1-0001:
1. Adds a planId field in PlannedStmt 2. Added an st_plan_id fields in PgBackendStatus 3. APIs to report and to retrieve a planId to PgBackendStatus An extension is able to set a planId in PlannedStmt directly, and while they can do the same for PgBackendStatus, I felt it is better to provide similar APIs for this as we do for queryId. Unless the extension passed force=true to the API, this will ensure that a planId already set either by a top-level statement or by another extension cannot be set when a plan is active. Also, the extension does not need to worry about resetting the planId at the end of execution as this will follow the same mechanism as is currently being done for queryId. This will remove responsibility from the extension author to have to manage this aspect. The extension should normally compute the planId in the planner or ExecutorStart hook. If the planId is computed in the planner_hook, the extension can set the planId in plannedStmt making the planId available to subsequent executions of a cached plan. What this patch does not cover is adding a "Plan Identifier" to explain output or to logs. Also, there is no core GUC like compute_query_id, since it does not make sense if we're not computing a planId in core. v2-0001: This adds a planId to pg_stat_get_activity ( not pg_stat_activity ). An extension can offer its own view, similar to pg_stat_activity, which can include planId. Note that there are no documentation updates required here as we don't have per-field documentation for pg_stat_get_activity. These 2 patches can probably be combined , but will leave them like this for now. Looking forward to feedback. Regards Sami
v1-0002-add-planId-to-pg_stat_get_activity.patch
Description: Binary data
v1-0001-Allow-plugins-to-set-a-64-bit-plan-identifier.patch
Description: Binary data
