On Wed, Oct 7, 2020 at 10:42:49AM +0900, Michael Paquier wrote: > 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.
Oh, if that is true, then I agree let's just go with the version number. > > 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. Good, much simpler. I think there is enough demand for a queryid that I would like to get this moving forward. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
