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.
Registration of an queryId generator implemented by analogy with
extensible methods machinery. Also, I switched queryId to int64 type and
renamed to 'label'.
Some lessons learned:
1. Single queryId implementation is deeply tangled with the core code
(stat reporting machinery and parallel workers as an example).
2. We need a custom queryId, that is based on a generated queryId
(according to the logic of pg_stat_statements).
3. We should think about safety of de-registering procedure.
4. We should reserve position of default in-core generator and think on
logic of enabling/disabling it.
5. We should add an EXPLAIN hook, to allow an extension to print this
custom queryId.
--
regards,
Andrey Lepikhov
Postgres Professional