public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrey V. Lepikhov <[email protected]>
To: Julien Rouhaud <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Tom Lane <[email protected]>
Subject: Re: Multiple Query IDs for a rewritten parse tree
Date: Mon, 10 Jan 2022 09:10:59 +0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <20220109121321.3d74krhjbr5mp4zv@jrouhaud>
References: <[email protected]>
	<[email protected]>
	<20220109121321.3d74krhjbr5mp4zv@jrouhaud>

On 1/9/22 5:13 PM, Julien Rouhaud wrote:
> 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.
> 
Do You mean JumbleState?
I think, registering queryId generator we should store also a pointer 
(void **args) to an additional data entry, as usual.

> 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.
> 
I can add one more use case.
Our extension for freezing query plan uses query tree comparison 
technique to prove, that the plan can be applied (and we don't need to 
execute planning procedure at all).
The procedure of a tree equality checking is expensive and we use 
cheaper queryId comparison to identify possible candidates. So here, for 
the better performance and queries coverage, we need to use query tree 
normalization - queryId should be stable to some modifications in a 
query text which do not change semantics.
As an example, query plan with external parameters can be used to 
execute constant query if these constants correspond by place and type 
to the parameters. So, queryId calculation technique returns also 
pointers to all constants and parameters found during the calculation.

-- 
regards,
Andrey Lepikhov
Postgres Professional

view thread (14+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Multiple Query IDs for a rewritten parse tree
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox