5 ms·
To avoid the issue of queries with IN() polluting pg stat statements, one can in most of the case replace WHERE a IN() With WHERE a = ANY() No matter the nu
by neamar 5y ago
To avoid the issue of queries with IN() polluting pg stat statements, one can in most of the case replace
WHERE a IN()
With
WHERE a = ANY()
No matter the number of options in the ANY operator, it'll hash to the same query id.
Semantics between ANY and IN are very slightly different, but 95% of the case it'll get the job done and provide better stats (by having all queries analyzed together).
- masklinn 5y ago> Semantics between ANY and IN are very slightly different, but 95% of the case it'll get the job done and provide better stats And it’ll be more reliable, because `any` will be happy to take an empty array while `IN` will be very cross if given an empty tuple.
- Shorn 5y ago> `any` will be happy > `in` will be very cross I like this. People should anthropomorphize their operators more.