No PostgreSQL, exatamente o que você obterá aqui depende da tabela subjacente, então você deve usar EXPLAIN ANALYZE em algumas consultas de amostra em um subconjunto útil de seus dados para descobrir exatamente o que o otimizador fará (certifique-se de que as tabelas que você estão concorrendo também foram ANALISADOS). IN pode ser processado de duas maneiras diferentes, e é por isso que você precisa examinar algumas amostras para descobrir qual alternativa está sendo usada para seus dados. Não existe uma resposta genérica simples para sua pergunta.
Quanto à pergunta específica que você adicionou em sua revisão, em relação a um conjunto de dados trivial sem índices envolvidos, aqui está um exemplo dos dois planos de consulta que você obterá:
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
Esses dois tempos de execução são essencialmente idênticos, porque o tempo real de processamento é dominado pela varredura sequencial na tabela; executando várias vezes mostra que a diferença entre os dois está abaixo da margem de erro de execução para execução. Como você pode ver, o PostgreSQL transforma o caso IN usando seu filtro ANY, que deve sempre executar mais rápido que uma série de ORs. Novamente, este caso trivial não é necessariamente representativo do que você verá em uma consulta séria onde índices e similares estão envolvidos. Independentemente disso, substituir manualmente INs por uma série de instruções OR nunca deve ser mais rápido, porque o otimizador sabe a melhor coisa a fazer aqui se tiver bons dados para trabalhar.
Em geral, o PostgreSQL conhece mais truques de como otimizar consultas complicadas do que o otimizador MySQL, mas também depende muito de você ter fornecido ao otimizador dados suficientes para trabalhar. Os primeiros links na seção "Performance Optimization" do wiki do PostgreSQL cobrem as coisas mais importantes necessárias para obter bons resultados do otimizador.
