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
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 |