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

From: Jeremy Schneider <schneider(at)ardentperf(dot)com>
To: Lukas Fittl <lukas(at)fittl(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Marko M <marko(at)pganalyze(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>
Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
Date: 2025-01-07 06:35:25
Message-ID: 20250106223525.13677921@jeremy-ThinkPad-T430s
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2 Jan 2025 12:46:04 -0800
Lukas Fittl <lukas(at)fittl(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou (Fujitsu) 2025-01-07 06:40:50 RE: Conflict detection for update_deleted in logical replication
Previous Message Masahiko Sawada 2025-01-07 06:32:52 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart