Re: Doc update for pg_stat_statements normalization - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Doc update for pg_stat_statements normalization
Date
Msg-id Y/1GLxKhfx8W0tUx@paquier.xyz
Whole thread Raw
In response to Re: Doc update for pg_stat_statements normalization  ("Imseih (AWS), Sami" <simseih@amazon.com>)
List pgsql-hackers
On Mon, Feb 27, 2023 at 10:53:26PM +0000, Imseih (AWS), Sami wrote:
> Wouldn't be less in terms of memory usage to just store the required
> JumbleState fields in Query[Desc]?
>
> clocations_count,
> highest_extern_param_id,
> clocations_locations,
> clocations_length

Yes, these would be enough to ensure a proper rebuild of the
normalized query in either the 2nd or 3rd call of pgss_store().  With
a high deallocation rate, perhaps we just don't care about bearing
the extra computation to build a normalized qury more than once, still
it could be noticeable?

Anything that gets changed is going to need some serious benchmarking
(based on deallocation rate, string length, etc.) to check that the
cost of this extra memory is worth the correctness gained when storing
the normalization.  FWIW, I am all in if it means code simplifications
with better performance and better correctness of the results.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Non-superuser subscription owners
Next
From: Vik Fearing
Date:
Subject: Re: SQL JSON path enhanced numeric literals