3 ms·
Actually, I’d think using “ANY” would be the clearest translation of the semantic intent. If your query processor is even marginally competent, ANY & EXISTS ar
by twoodfin 3y ago
Actually, I’d think using “ANY” would be the clearest translation of the semantic intent.
If your query processor is even marginally competent, ANY & EXISTS are indeed optimized exactly the same way.
A slightly smarter QP will perform as well for the equivalent IN condition, too.
- sgarland 3y agoTangentially related, how IN and ANY can produce wildly different results [0] due to type casting. I have personally seen this, and at least for my data, the fastest query / fewest buffers scanned was to shift the matching ids out to a CTE with VALUES, and join with IN. It wasn’t a minor speed up, either, it was literally twice as fast. [0]: https://dba.stackexchange.com/a/125500 https://dba.stackexchange.com/a/125500