title: Pre-fetching row counts before query - performance
body: <p>I recently answered this question based on my experience:</p>
  
  <p><a href="https://stackoverflow.com/questions/11642975/counting-rows-before-proceeding-to-actual-searching/11643053#11643053">Counting rows before proceeding to actual searching</a></p>
  
  <p>but I'm not 100% satisfied with the answer I gave.  </p>
  
  <p>The question is basically this: Can I get a performance improvement by running a <code>COUNT</code> over a particular query before deciding to run the query that brings back the actual rows?</p>
  
  <p>My intuition is this: you will only save the I/O and wire time associated with retrieving the data instead of the count because to count the data, you need to actually find the rows.  The possible exception to this is when the query is a simple function of the indexes.</p>
  
  <p>My question then is this: Is this always true? What other exception cases are there?  From a pure performance perspective, in what cases would one want to do a <code>COUNT</code> before running the full query?  </p>