> On Fri, Jan 21, 2022 at 11:33:22AM +0500, Andrey V. Lepikhov wrote: > On 1/9/22 5:49 AM, 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. We could > > probably get away with saying that all such hash values must be uint64. > > The main difference from your function-OID idea, I think, is that > > I'm envisioning the tags as being small integers with well-known > > values, similarly to the way we manage stakind values in pg_statistic. > > In this way, an extension that wants a hash that the core knows how > > to calculate doesn't need its own copy of the code, and similarly > > one extension could publish a calculation method for use by other > > extensions. > > To move forward, I have made a patch that implements this idea (see > attachment). It is a POC, but passes all regression tests.
Thanks. Couple of comments off the top of my head: > Registration of an queryId generator implemented by analogy with extensible > methods machinery. Why not more like suggested with stakind and slots in some data structure? All of those generators have to be iterated anyway, so not sure if a hash table makes sense. > Also, I switched queryId to int64 type and renamed to > 'label'. A name with "id" in it would be better I believe. Label could be think of as "the query belongs to a certain category", while the purpose is identification. > 2. We need a custom queryId, that is based on a generated queryId (according > to the logic of pg_stat_statements). Could you clarify? > 4. We should reserve position of default in-core generator >From the discussion above I was under the impression that the core generator should be distinguished by a predefined kind. > 5. We should add an EXPLAIN hook, to allow an extension to print this custom > queryId. Why? It would make sense if custom generation code will be generating some complex structure, but the queryId itself is still a hash.
