public inbox for [email protected]  

help / color / mirror / Atom feed

From: Julien Rouhaud <[email protected]>
To: Dmitry Dolgov <[email protected]>
Cc: Andrey V. Lepikhov <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Multiple Query IDs for a rewritten parse tree
Date: Sun, 30 Jan 2022 01:48:20 +0800
Message-ID: <20220129174820.nnqi7zzs5r4dkfmm@jrouhaud> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<20220129075133.75kt254672mldefy@jrouhaud>
	<[email protected]>

Hi,

On Sat, Jan 29, 2022 at 06:12:05PM +0100, Dmitry Dolgov wrote:
> > On Sat, Jan 29, 2022 at 03:51:33PM +0800, Julien Rouhaud wrote:
> >
> > I'm also unsure of how are extensions supposed to cooperate in general, as
> > I feel that queryids should be implemented for some "intent" (like monitoring,
> > planning optimization...).  That being said I'm not sure if e.g. AQO heuristics
> > are too specific for its need or if it could be shared with other extension
> > that might be dealing with similar concerns.
> 
> Assuming there are multiple providers and consumers of queryIds, every
> such consumer extension needs to know which type of queryId it wants to
> use. E.g. in case of pg_stat_statements, it needs to be somehow
> configured to know which of those kinds to take, to preserve
> extensibility you're talking about. Does the answer make sense, or did
> you mean something else?

I guess, but I don't think that the proposed approach does that.

The DBA should be able to configure a monitoring queryid provider, a planning
queryid provider... and the extensions should have a way to know which is
which.  And also I don't think that the DBA should be allowed to setup multiple
monitoring queryid providers, nor change them dynamically.

> Btw, the approach in this thread still doesn't give a clue what to do
> when an extension needs to reuse some parts of core queryId generator,
> as in case with pg_stat_statements and "IN" condition merging.

Indeed, as the query text normalization is not extensible.

view thread (4+ messages)

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], [email protected]
  Subject: Re: Multiple Query IDs for a rewritten parse tree
  In-Reply-To: <20220129174820.nnqi7zzs5r4dkfmm@jrouhaud>

* 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