> > > I perhap meant "missing chunk" instead of "trimming". To me it just > > > looked like a trimmed text, which was wrong. Looks like v25 > > > deals with that better at least. I am just not sure about all that we are > > > doing > > > here as I believe it may open up big changes for bugs generating the > > > normalized > > > query texts. I'm a bit worried about that. IMO, we are better off just > > > adding a comment > > > at the start of a query that this query text such as "/* > > > query_id_squash_values */" > > > and keeping all the parameter symbols in-place. > > > > I see what you mean, but keeping everything in place is partially > > defeating purpose of the patch. The idea is not only to make those > > queries to have the same query_id, but also to reduce the size of > > queries themselves. E.g. the use case scenario that has triggered the > > patch was about queries having dozens of thousands of such constants, > > so that the size of them was a burden on its own. > > My experience with this issue is not so much the size of the query text, > but it's the fact that similar queries ( with varying length IN-lists ) being > tracked in different entries, causing high deallocation and heavy > garbage collection. This is besides the overall loss of quality of > the data from pg_stat_statements if there is constant deallocation. > > But, with what you are doing with this patch, we will now have > a single tracking entry for similar queries with varying IN-lists and > even if the query text is *large*, it's only a single entry tracking > and we are no longer continuously deallocating and garbage > collecting as frequently.
Another point, I think if we want to control the size of the query texts, that could be something that is maybe useful overall for pg_stat_statements, not just for IN-list type queries. -- Sami
