public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrey 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 15:24:46 +0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <Ydv02rKq2pL9ONcn@jrouhaud>
References: <[email protected]>
	<[email protected]>
	<20220109121321.3d74krhjbr5mp4zv@jrouhaud>
	<[email protected]>
	<Ydu7a08KPZKz4sUC@jrouhaud>
	<[email protected]>
	<Ydv02rKq2pL9ONcn@jrouhaud>

On 10/1/2022 13:56, Julien Rouhaud wrote:
> On Mon, Jan 10, 2022 at 12:37:34PM +0500, Andrey V. Lepikhov wrote:
>> I think, pg_stat_statements can live with an queryId generator of the
>> sr_plan extension. But It replaces all constants with $XXX parameter at the
>> query string. In our extension user defines which plan is optimal and which
>> constants can be used as parameters in the plan.
> 
> I don't know the details of that extension, but I think that it should work as
> long as you have the constants information in the jumble state, whatever the
> resulting normalized query string is right?
Yes. the same input query string doesn't prove that frozen query plan 
can be used, because rewrite rules could be changed. So we use only a 
query tree. Here we must have custom jumbling implementation.
queryId in this extension defines two aspects:
1. How many input queries will be compared with a query tree template of 
the frozen statement.
2. As a result, performance overheads on unsuccessful comparings.
> 
>> One drawback I see here - creating or dropping of my extension changes
>> behavior of pg_stat_statements that leads to distortion of the DB load
>> profile. Also, we haven't guarantees, that another extension will work
>> correctly (or in optimal way) with such queryId.
> 
> But then, if generating 2 queryid is a better for performance, does the
> extension really need an additional jumble state and/or normalized query
> string?
Additional Jumble state isn't necessary, but it would be better for 
performance to collect pointers to all constant nodes during a process 
of hash generation.

-- 
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