In PostgreSQL, esattamente ciò che otterrai qui dipende dalla tabella sottostante, quindi dovresti usare EXPLAIN ANALYZE su alcune query di esempio rispetto a un utile sottoinsieme dei tuoi dati per capire esattamente cosa farà l'ottimizzatore (assicurati che le tabelle sono stati ANALIZZATI anche contro quelli in esecuzione). IN può essere elaborato in un paio di modi diversi, ed è per questo che è necessario esaminare alcuni campioni per capire quale alternativa viene utilizzata per i dati. Non esiste una risposta generica semplice alla tua domanda.
Per quanto riguarda la domanda specifica che hai aggiunto nella tua revisione, a fronte di un set di dati banale senza indici coinvolti, ecco un esempio dei due piani di query che otterrai:
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
Questi due tempi di esecuzione sono essenzialmente identici, perché il tempo di elaborazione reale è dominato dalla scansione sequenziale attraverso la tabella; l'esecuzione più volte mostra che la differenza tra i due è inferiore al margine di errore run to run. Come puoi vedere, PostgreSQL trasforma il caso IN nell'usare il suo filtro ANY, che dovrebbe sempre essere eseguito più velocemente di una serie di OR. Ancora una volta, questo caso banale non è necessariamente rappresentativo di ciò che vedrai su una query seria in cui sono coinvolti indici e simili. In ogni caso, la sostituzione manuale di IN con una serie di istruzioni OR non dovrebbe mai essere più veloce, perché l'ottimizzatore sa qual è la cosa migliore da fare qui se ha dati validi con cui lavorare.
In generale, PostgreSQL conosce più trucchi su come ottimizzare le query complicate rispetto all'ottimizzatore MySQL, ma fa anche molto affidamento sul fatto che tu abbia fornito all'ottimizzatore dati sufficienti con cui lavorare. I primi collegamenti nella sezione "Ottimizzazione delle prestazioni" del wiki di PostgreSQL coprono le cose più importanti necessarie per ottenere buoni risultati dall'ottimizzatore.
