Re: Refactor query normalization into core query jumbling
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: zengman <zengman@halodbtech.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-01-05T22:19:27Z
Lists: pgsql-hackers
> === 1 > > + SetConstantLengths((JumbleState *) jstate, query, query_loc); > > This cast seems unnecessary. Right. This is unnecessary. I will remove in the next iteration. > === 2 > > +CompLocation(const void *a, const void *b) > > In the commit message I can see "Functions are renamed to match core naming > conventions" but wasn't comp_location() better? Not sure if it's better or worse. I aimed for consistency here and used pascal case to match. > === 3 > > + /* > + * generate the normalized query. Note that the normalized > + * representation may well vary depending on just which > + * "equivalent" query is used to create the hashtable entry. We > + * assume this is OK. > + */ > + norm_query = GenerateNormalizedQuery(jstate, query, > > Should part of this comment be on top of the GenerateNormalizedQuery() > definition instead? No, because this talks about the hashtable entry which is specific to pg_stat_statements. -- Sami Imseih Amazon Web Services (AWS)
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Mark JumbleState as a const in the post_parse_analyze hook
- 49cc0d41488b 19 (unreleased) landed
-
Force standard_conforming_strings to always be ON.
- 45762084545e 19 (unreleased) cited
-
Move pg_stat_statements query jumbling to core.
- 5fd9dfa5f50e 14.0 cited