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.

-- 
Sami