On Sat, Jan 08, 2022 at 07:49:59PM -0500, Tom Lane wrote:
>
> The idea I'd been vaguely thinking about is to allow attaching a list
> of query-hash nodes to a Query, where each node would contain a "tag"
> identifying the specific hash calculation method, and also the value
> of the query's hash calculated according to that method.
For now the queryid mixes two different things: fingerprinting and query text
normalization. Should each calculation method be allowed to do a different
normalization too, and if yes where should be stored the state data needed for
that? If not, we would need some kind of primary hash for that purpose.
Looking at Andrey's use case for wanting multiple hashes, I don't think that
adaptive optimization needs a normalized query string. The only use would be
to output some statistics, but this could be achieved by storing a list of
"primary queryid" for each adaptive entry. That's probably also true for
anything that's not monitoring intended. Also, all monitoring consumers should
probably agree on the same queryid, both fingerprint and normalized string, as
otherwise it's impossible to cross-reference metric data.
