I wrote: > Peter Geoghegan <p...@heroku.com> writes: >> 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.
> I think this is a vastly oversimplified explanation of the problem. > In particular, because the planner will flatten an ArrayExpr containing > only Const nodes to an array constant (see eval_const_expressions), > I don't believe the case ever arises in exactly the form you posit here. Um ... disregard that. For some reason I was thinking that pg_stat_statements looks at plan trees, but of course what it looks at is the query tree immediately post-parse-analysis. So the behavior of the const-folding pass is not relevant. The heuristics in transformAExprIn() are still relevant, though, and I suspect that the question of whether Params should be considered the same as Consts is also highly relevant. I wonder whether we could improve this by arranging things so that both Consts and Params contribute zero to the jumble hash, and a list of these things also contributes zero, regardless of the length of the list. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers