Re: Multiple Query IDs for a rewritten parse tree - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Multiple Query IDs for a rewritten parse tree
Date
Msg-id 20220109114306.wwr5znquhhrqqvoc@erthalion.local
Whole thread Raw
In response to Re: Multiple Query IDs for a rewritten parse tree  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Multiple Query IDs for a rewritten parse tree
List pgsql-hackers
> 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.  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.

An extension that wants a slightly modified version of hash calculation
implementation from the core would still need to copy everything. The
core probably has to provide more than one (hash, method) pair to cover
some basic needs.



pgsql-hackers by date:

Previous
From: "sergei sh."
Date:
Subject: Re: [PATCH] reduce page overlap of GiST indexes built using sorted method
Next
From: Julien Rouhaud
Date:
Subject: Re: Multiple Query IDs for a rewritten parse tree