Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity
Date
Msg-id 20220616051938.g3wf7rlgyuo4rohj@jrouhaud
Whole thread Raw
In response to [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Responses Re: [PROPOSAL] Detecting plan changes with plan_id in pg_stat_activity  ("Imseih (AWS), Sami" <simseih@amazon.com>)
List pgsql-hackers
Hi,

On Wed, Jun 15, 2022 at 06:45:38PM +0000, Imseih (AWS), Sami wrote:
> Adding a plan_id to pg_stat_activity allows users
> to determine if a plan for a particular statement
> has changed and if the new plan is performing better
> or worse for a particular statement.
> [...]
> Attached is a POC patch that computes the plan_id
> and presents the top-level plan_id in pg_stat_activity.

AFAICS you're proposing to add an identifier for a specific plan, but no way to
know what that plan was?  How are users supposed to use the information if they
know something changed but don't know what changed exactly?

> - In the POC, the compute_query_id GUC determines if a
>   plan_id is to be computed. Should this be a separate GUC?

Probably, as computing it will likely be quite expensive.  Some benchmark on
various workloads would be needed here.

I only had a quick look at the patch, but I see that you have some code to
avoid storing the query text multiple times with different planid.  How does it
work exactly, and does it ensure that the query text is only removed once the
last entry that uses it is removed?  It seems that you identify a specific
query text by queryid, but that seems wrong as collision can (easily?) happen
in different databases.  The real identifier of a query text should be (dbid,
queryid).

Note that this problem already exists, as the query texts are now stored per
(userid, dbid, queryid, istoplevel).  Maybe this part could be split in a
different commit as it could already be useful without a planid.



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Extending USING [heap | mytam | yourtam] grammar and behavior
Next
From: Mark Dilger
Date:
Subject: Re: Modest proposal to extend TableAM API for controlling cluster commands