En PostgreSQL, exactamente lo que obtendrá aquí depende de la tabla subyacente, por lo que debe usar EXPLAIN ANALYZE en algunas consultas de muestra contra un subconjunto útil de sus datos para averiguar exactamente qué hará el optimizador (asegúrese de que las tablas que en contra también han sido ANALIZADOS). IN se puede procesar de un par de maneras diferentes, y es por eso que necesita mirar algunas muestras para averiguar qué alternativa se está utilizando para sus datos. No hay una respuesta genérica simple a su pregunta.
En cuanto a la pregunta específica que agregó en su revisión, contra un conjunto de datos triviales sin índices involucrados, aquí hay un ejemplo de los dos planes de consulta que obtendrá:
postgres=# explain analyze select * from x where s in ('123','456');
Seq Scan on x (cost=0.00..84994.69 rows=263271 width=181) (actual time=0.015..1819.702 rows=247823 loops=1)
Filter: (s = ANY ('{123,456}'::bpchar[]))
Total runtime: 1931.370 ms
postgres=# explain analyze select * from x where s='123' or s='456';
Seq Scan on x (cost=0.00..90163.62 rows=263271 width=181) (actual time=0.014..1835.944 rows=247823 loops=1)
Filter: ((s = '123'::bpchar) OR (s = '456'::bpchar))
Total runtime: 1949.478 ms
Esos dos tiempos de ejecución son esencialmente idénticos, porque el tiempo de procesamiento real está dominado por el escaneo secuencial en la tabla; ejecutar varias veces muestra que la diferencia entre los dos está por debajo del margen de error de ejecución a ejecución. Como puede ver, PostgreSQL transforma el caso IN para usar su filtro ANY, que siempre debería ejecutarse más rápido que una serie de OR. Una vez más, este caso trivial no es necesariamente representativo de lo que verá en una consulta seria donde están involucrados índices y similares. De todos modos, reemplazar manualmente IN con una serie de declaraciones OR nunca debería ser más rápido, porque el optimizador sabe qué es lo mejor que puede hacer aquí si tiene buenos datos con los que trabajar.
En general, PostgreSQL conoce más trucos sobre cómo optimizar consultas complicadas que el optimizador de MySQL, pero también depende en gran medida de que le haya dado al optimizador suficientes datos para trabajar. Los primeros enlaces en la sección "Optimización del rendimiento" de la wiki de PostgreSQL cubren las cosas más importantes necesarias para obtener buenos resultados del optimizador.
