[rossmohax]

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)

[SigmundA]

>every query has to be planned

I thought PG planned every query anyway, it does not do plan caching.

[rossmohax]

It does, but AFAIk only for prepapred queries and cache is local to the backend serving query. See `plan_cache_mode` param.