Date: Mon, 10 Jan 2022 16:56:58 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: "Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: Multiple Query IDs for a rewritten parse tree
Message-ID: <Ydv02rKq2pL9ONcn@jrouhaud>
References: <e0de3423-4bba-1e69-c55a-f76bf18dbd74@postgrespro.ru>
 <1606733.1641689399@sss.pgh.pa.us>
 <20220109121321.3d74krhjbr5mp4zv@jrouhaud>
 <1ea9d518-becb-1c3d-dc6c-e0045d3101de@postgrespro.ru>
 <Ydu7a08KPZKz4sUC@jrouhaud>
 <e825ae62-808b-fa2e-057f-f47d5af1c04e@postgrespro.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e825ae62-808b-fa2e-057f-f47d5af1c04e@postgrespro.ru>
Archived-At: <https://www.postgresql.org/message-id/Ydv02rKq2pL9ONcn%40jrouhaud>
Precedence: bulk

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?

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