On Tue, Oct 06, 2020 at 09:22:29AM -0400, Bruce Momjian wrote: > I propose moving the pg_stat_statements queryid hash code into the > server (with a version number), and also adding a postgresql.conf > variable that lets you control how detailed the queryid hash is > computed. This addresses the problem of people wanting different hash > methods.
In terms of making this part expendable in the future, there could be a point in having an enum here, but are we sure that we will have a need for that in the future? What I get from this discussion is that we want a unique source of truth that users can consume, and that the only source of truth proposed is the PGSS hashing. We may change the way we compute the query ID in the future, for example if it gets expanded to some utility statements, etc. But that would be controlled by the version number in the hash, not the GUC itself. > When computing a hash, the queryid detail level and version number will > be mixed into the hash, so only a hash that used a similar query and > identical queryid detail level would match. Yes, having a version number directly dependent on the hashing sounds like a good compromise to me. -- Michael
signature.asc
Description: PGP signature
