diff options
author | Michael Paquier <michael@paquier.xyz> | 2025-03-24 13:23:42 +0900 |
---|---|---|
committer | Michael Paquier <michael@paquier.xyz> | 2025-03-24 13:23:42 +0900 |
commit | 2a0cd38da5ccf70461c51a489ee7d25fcd3f26be (patch) | |
tree | 000fe6d92b36523695dcb368d699ecf2ecd0f191 /src/backend/utils/activity/backend_status.c | |
parent | 8a3e4011f02dd2789717c633e74fefdd3b648386 (diff) | |
download | postgresql-2a0cd38da5ccf70461c51a489ee7d25fcd3f26be.tar.gz postgresql-2a0cd38da5ccf70461c51a489ee7d25fcd3f26be.zip |
Allow plugins to set a 64-bit plan identifier in PlannedStmt
This field can be optionally set in a PlannedStmt through the planner
hook, giving extensions the possibility to assign an identifier related
to a computed plan. The backend is changed to report it in the backend
entry of a process running (including the extended query protocol), with
semantics and APIs to set or get it similar to what is used for the
existing query ID (introduced in the backend via 4f0b0966c8). The plan
ID is reset at the same timing as the query ID. Currently, this
information is not added to the system view pg_stat_activity; extensions
can access it through PgBackendStatus.
Some patches have been proposed to provide some features in the planning
area, where a plan identifier is used as a key to know the plan involved
(for statistics, plan storage and manipulations, etc.), and the point of
this commit is to provide an anchor in the backend that extensions can
rely on for future work. The reset of the plan identifier is
controlled by core and follows the same pattern as the query identifier
added in 4f0b0966c8.
The contents of this commit are extracted from a larger set proposed
originally by Lukas Fittl, that Sami Imseih has proposed as an
independent change, with a few tweaks sprinkled by me.
Author: Lukas Fittl <lukas@fittl.com>
Author: Sami Imseih <samimseih@gmail.com>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/CAP53Pkyow59ajFMHGpmb1BK9WHDypaWtUsS_5DoYUEfsa_Hktg@mail.gmail.com
Discussion: https://postgr.es/m/CAA5RZ0vyWd4r35uUBUmhngv8XqeiJUkJDDKkLf5LCoWxv-t_pw@mail.gmail.com
Diffstat (limited to 'src/backend/utils/activity/backend_status.c')
-rw-r--r-- | src/backend/utils/activity/backend_status.c | 58 |
1 files changed, 58 insertions, 0 deletions
diff --git a/src/backend/utils/activity/backend_status.c b/src/backend/utils/activity/backend_status.c index 7681b4ba5a9..e1576e64b6d 100644 --- a/src/backend/utils/activity/backend_status.c +++ b/src/backend/utils/activity/backend_status.c @@ -321,6 +321,7 @@ pgstat_bestart_initial(void) lbeentry.st_progress_command = PROGRESS_COMMAND_INVALID; lbeentry.st_progress_command_target = InvalidOid; lbeentry.st_query_id = UINT64CONST(0); + lbeentry.st_plan_id = UINT64CONST(0); /* * we don't zero st_progress_param here to save cycles; nobody should @@ -599,6 +600,7 @@ pgstat_report_activity(BackendState state, const char *cmd_str) /* st_xact_start_timestamp and wait_event_info are also disabled */ beentry->st_xact_start_timestamp = 0; beentry->st_query_id = UINT64CONST(0); + beentry->st_plan_id = UINT64CONST(0); proc->wait_event_info = 0; PGSTAT_END_WRITE_ACTIVITY(beentry); } @@ -659,7 +661,10 @@ pgstat_report_activity(BackendState state, const char *cmd_str) * identifier. */ if (state == STATE_RUNNING) + { beentry->st_query_id = UINT64CONST(0); + beentry->st_plan_id = UINT64CONST(0); + } if (cmd_str != NULL) { @@ -710,6 +715,44 @@ pgstat_report_query_id(uint64 query_id, bool force) PGSTAT_END_WRITE_ACTIVITY(beentry); } +/* -------- + * pgstat_report_plan_id() - + * + * Called to update top-level plan identifier. + * -------- + */ +void +pgstat_report_plan_id(uint64 plan_id, bool force) +{ + volatile PgBackendStatus *beentry = MyBEEntry; + + /* + * if track_activities is disabled, st_plan_id should already have been + * reset + */ + if (!beentry || !pgstat_track_activities) + return; + + /* + * We only report the top-level plan identifiers. The stored plan_id is + * reset when a backend calls pgstat_report_activity(STATE_RUNNING), or + * with an explicit call to this function using the force flag. If the + * saved plan identifier is not zero it means that it's not a top-level + * command, so ignore the one provided unless it's an explicit call to + * reset the identifier. + */ + if (beentry->st_plan_id != 0 && !force) + return; + + /* + * Update my status entry, following the protocol of bumping + * st_changecount before and after. We use a volatile pointer here to + * ensure the compiler doesn't try to get cute. + */ + PGSTAT_BEGIN_WRITE_ACTIVITY(beentry); + beentry->st_plan_id = plan_id; + PGSTAT_END_WRITE_ACTIVITY(beentry); +} /* ---------- * pgstat_report_appname() - @@ -1107,6 +1150,21 @@ pgstat_get_my_query_id(void) } /* ---------- + * pgstat_get_my_plan_id() - + * + * Return current backend's plan identifier. + */ +uint64 +pgstat_get_my_plan_id(void) +{ + if (!MyBEEntry) + return 0; + + /* No need for a lock, for roughly the same reasons as above. */ + return MyBEEntry->st_plan_id; +} + +/* ---------- * pgstat_get_backend_type_by_proc_number() - * * Return the type of the backend with the specified ProcNumber. This looks |