Re: [PATCH] Optionally record Plan IDs to track plan changes for a query - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
Date
Msg-id Z6v3dSJ7yEJ9xai4@jrouhaud
Whole thread Raw
In response to Re: [PATCH] Optionally record Plan IDs to track plan changes for a query  (Lukas Fittl <lukas@fittl.com>)
List pgsql-hackers
On Wed, Feb 12, 2025 at 09:08:00AM +0900, Michael Paquier wrote:
> Wikipedia seems to agree with you that "fingerprint" would fit for
> this purpose, though:
> https://en.wikipedia.org/wiki/Fingerprint_(computing)
>
> Has anybody any comments about that?  That would be a large renaming,
> but in the long term is makes sense if we want to apply that to more
> than just parse nodes and query strings.  If you do that, it impacts
> the file names and the properties, that are hidden in the backend for
> most of it, except the entry API and JumbleState.  This last part
> impacts some extensions and I have been maintaining one a bit
> (pg_hint_plan).

I agree that fingerprint is a good improvement.

>
> Also adding Julien in CC,
> as he has some out-of-core extension code that depends on the jumbling
> structures if I recall correctly.

I do have an extension to support custom fingerprinting logic, but the
introduction of the pg_node_attr based jumbling kind of broke it.

FTR my main motivation was to be able to deal with queries referencing
temporary relations, as if your application creates a lot of those it basically
means that you cannot use pg_stat_statements anymore.



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided.
Next
From: Julien Rouhaud
Date:
Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a query