Re: pg_stat_statements and "IN" conditions

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