Horton

Re: [PATCH] Optionally record Plan IDs to track plan changes for a query

Jeremy Schneider <schneider@ardentperf.com>

View thread View on postgr.es
From: Jeremy Schneider <schneider@ardentperf.com>
To: Lukas Fittl <lukas@fittl.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Marko M <marko@pganalyze.com>, Sami Imseih <samimseih@gmail.com>
Date: 2025-01-07T06:35:25Z
Lists: pgsql-hackers 
On Thu, 2 Jan 2025 12:46:04 -0800
Lukas Fittl <lukas@fittl.com> wrote:

> this proposed patch set adds:
> 
> 1. An updated in-core facility to optionally track Plan IDs based on
> hashing the plan nodes during the existing treewalk in setrefs.c -
> controlled by the new "compute_plan_id" GUC
> 2. An example user of plan IDs with a new pg_stat_plans extension in
> contrib, that also records the first plan text with EXPLAIN (COSTS
> OFF)
> 
> My overall perspective is that (1) is best done in-core to keep
> overhead low, whilst (2) could be done outside of core (or merged
> with a future pg_stat_statements) and is included here mainly for
> illustration purposes.

And 2025 is starting with a bang! Nice to see this email! Being able to
collect telemetry that indicates when plan changes happened would be
very useful.

The specifics of how a plan ID is generated are going to have some edge
cases (as you noted)

I concur that the ideal place for this to eventually land would be
alongside queryid in pg_stat_activity

-Jeremy

Commits

  1. doc: Update header file mention for CompareType

  2. Allow plugins to set a 64-bit plan identifier in PlannedStmt

  3. Fix indentation of comment in plannodes.h

  4. Reformat node comments in plannodes.h

  5. injection_points: Add routine able to drop all stats

  6. Add pgstat_drop_matching_entries() to pgstats

  7. Move pg_stat_statements query jumbling to core.