pg_stat_statements' fingerprinting logic considers the following two statements as distinct:
select 1 in (1, 2, 3); select 1 in (1, 2, 3, 4); This is because the ArrayExpr jumble case jumbles any ArrayExpr's list of elements recursively. In this case it's a list of Const nodes, and the fingerprinting logic jumbles those nodes indifferently. Somebody told me that they think that pg_stat_statements should not do that. This person felt that it would be preferable for such expressions to be normalized without regard to the number of distinct Const elements. I suppose that that would work by determing if the ArrayExpr elements list was a list of Const nodes and only const nodes. Iff that turned out to be the case, something else would be jumbled (something other than the list) that would essentially be a representation of "some list of zero or more (or maybe one or more) Const nodes with consttype of, in this example, 23". I think that this would make at least one person happy, because of course the two statements above would have their costs aggregated within a single pg_stat_statements entry. I'm not sure that I agree, but there is anecdata that suggests that it isn't uncommon for these sorts of queries to be broken out when they're all traceable back to a single point in the application (apparently it's common for Django apps to do so, perhaps questionably). If we assume that doing what I've described has no real downside, then it would probably be worth implementing. Plus I'm pretty sure that tools that do regex normalization are already doing something analogous. Thoughts? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers