From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Multiple Query IDs for a rewritten parse tree |
Date: | 2022-01-10 08:56:58 |
Message-ID: | Ydv02rKq2pL9ONcn@jrouhaud |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2022-01-10 09:10:47 | Re: reporting TID/table with corruption error |
Previous Message | Peter Eisentraut | 2022-01-10 08:53:48 | Re: SQL:2011 application time |