Getting by list of ids: `unnest() JOIN` vs `= ANY()`

Here I have an array of 42 ids from a table of 800,000 and I want to lookup the rows with those ids. I know of two ways to do this (besides creating a lot of parameters -- that one is harder to write -- assume it's off the table): # unnest() JOIN EXPLAIN ANALYZE SELECT * FROM unnest('{234095,2366560,234391,234480,239511,237504,239629,247756,239142,232372,2366563,238511,242756,243396,235301,240990,233823,234537,246556,240453,245295,238909,236157,233724,236514,245384,249595,239953,233381,232180,232242,232990,237354,2366572,232066,242180,239958,239036,2366578,2166609,2197037,236542}'::int[]) AS d(id) JOIN phi.patient AS p ON d.id = p.id; Nested Loop (cost=0.43..345.25 rows=100 width=133) (actual time=0.049..0.326 rows=42 loops=1) -> Function Scan on unnest d (cost=0.00..1.00 rows=100 width=4) (actual time=0.015..0.025 rows=42 loops=1) -> Index Scan using patient_pkey on patient p (cost=0.42..3.44 rows=1 width=129) (actual time=0.006..0.006 rows=1 loops=42) Index Cond: (id = d.id) Planning Time: 0.200 ms Execution Time: 0.374 ms (6 rows) # = ANY() EXPLAIN ANALYZE SELECT * FROM phi.patient WHERE id = ANY('{234095,2366560,234391,234480,239511,237504,239629,247756,239142,232372,2366563,238511,242756,243396,235301,240990,233823,234537,246556,240453,245295,238909,236157,233724,236514,245384,249595,239953,233381,232180,232242,232990,237354,2366572,232066,242180,239958,239036,2366578,2166609,2197037,236542}'); Index Scan using patient_pkey on patient (cost=0.42..119.51 rows=42 width=129) (actual time=0.049..0.258 rows=42 loops=1) Index Cond: (id = ANY ('{234095,2366560,234391,234480,239511,237504,239629,247756,239142,232372,2366563,238511,242756,243396,235301,240990,233823,234537,246556,240453,245295,238909,236157,233724,236514,245384,249595,239953,233381,232180,232242,232990,237354,2366572,232066,242180,239958,239036,2366578,2166609,2197037,236542}'::bigint[])) Planning Time: 0.162 ms Execution Time: 0.295 ms (4 rows) --- In this simple testing and testing with ~700 ids, I see no discernible difference between these approaches. But they produce different query plans. And it past, I remember encountering performance differences (though unfortunately I can't seem to repro them now). Are these two approaches materially different? Is there a reason to prefer one over the other? One thing that I thought of was that unnest can work for a composite key lookup (searching by two indexed fields, not just one).