A surprising performance problem with single-element lists for IN vs ANY

*Find the article on our blog here:* https://pganalyze.com/blog/5mins-postgres-performance-in-vs-any

In E75 of “5mins of Postgres” we're going to talk about a surprising case Kaarel Moppel ran into, where using "IN" is faster than "ANY". We investigate this edge case in detail and are also looking at Tom Lane's response, who is one of the main authors of a lot of Postgres planner logic, to Kaarel's case.

*Learn more about pganalyze:*

https://pganalyze.com

https://pganalyze.com/newsletter

https://twitter.com/pganalyze/

*Check out the pganalyze library for eBooks, webinars, and more:*

https://pganalyze.com/resources

📑 *What we have discussed in this episode of 5mins of Postgres:*

*TIL - IN is not the same as ANY - by Kaarel Moppel*

https://kmoppel.github.io/2023-07-04-til-in-is-not-the-same-as-any/

*Kaarel Moppel on GitHub*

https://github.com/kmoppel

*5mins of Postgres E45: IN lists vs ANY operator: Bind parameters and performance*

https://pganalyze.com/blog/5mins-postgres-performance-in-lists-vs-any-operator-bind-parameters

*BUG #17922: ANY vs IN execution plan difference for a single explicit input value - Kaarel’s bug report to the mailing list*

https://www.postgresql.org/message-id/flat/17922-1e2e0aeedd294424%40postgresql.org