title: Is it reasonable to stuff 1000 ids into a SELECT ... WHERE ... IN (...) query on Postgres?
body: <blockquote>
    <p><strong>Possible Duplicate:</strong><br>
    <a href="https://stackoverflow.com/questions/1009706/postgresql-max-number-of-parameters-in-in-clause">PostgreSQL - max number of parameters in &ldquo;IN&rdquo; clause?</a>  </p>
  </blockquote>
  
  
  
  <p>I'm developing a web API to perform RESTful queries on a resource that maps nicely to a Postgres table. Most of the filtering parameters also map nicely to parameters on the SQL query. A few of the filtering parameters, however, require a call to my search index (in this case, a Sphinx server). </p>
  
  <p>The simplest thing to do is to run my search, collect the primary keys from the search results, and stuff those into an <code>IN (...)</code> clause on the SQL query. However, since the search could return a lot of primary keys, I wonder if this such a bright idea.</p>
  
  <p>I expect that most of the time (say, 90%), my search will be returning results on the order of a few hundred. Perhaps 10% of the time, there will be on the order of several thousand results.</p>
  
  <p>Is this a reasonable approach? Is there a better way?</p>