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

On Wed, Feb 12, 2025 at 09:20:53AM +0800, Julien Rouhaud wrote:
> 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.

Okay, thanks.  So this would mean something for the file names, the
node_attr names, the structures and the APIs if we put all that under
the same label.

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

Do you have an issue more details about your problem?  If we can
improve the situation in core without impacting the existing cases
that we need to support in pgss, that may be worth looking at.
--
Michael