Please use neither. Reason is as number of lookups varies, you'll have to template query as a string adding either values to IN list or `OR` conditions. Not only it causes excessive string concatenation on your app side, these queries are also seen as distinct queries which has following drawbacks:
- every query has to be planned
- your DB driver can't prepare query as they are all different
- collecting per query stats becomes nightmare if number of arguments per query varies in wide range. metrics cardinality is a problem.
Correct way to handle it is pass all args as single parameter of type array and use `= ANY($1)` or if there are multiple columns build a virtual table and join:
SELECT a,b FROM table
NATURAL JOIN ROWS FROM (
unnest($1::type_of_a[]),
unnest($2::type_of_b[])
) t(a,b)
I thought PG planned every query anyway, it does not do plan caching.