title: Should I commit or rollback a transaction that creates a temp table, reads, then deletes it?
body: <p>To select information related to a list of hundreds of IDs... rather than make a huge select statement, I create temp table, insert the ids into it, join it with a table to select the rows matching the IDs, then delete the temp table.  So this is essentially a read operation, with no permanent changes made to any persistent database tables.</p>
  
  <p>I do this in a transaction, to ensure the temp table is deleted when I'm finished.  My question is... what happens when I commit such a transaction vs. let it roll it back?</p>
  
  <p>Performance-wise... does the DB engine have to do more work to roll back the transaction vs committing it?  Is there even a difference since the only modifications are done to a temp table?</p>
  
  <p>Related question here, but doesn't answer my specific case involving temp tables: <a href="https://stackoverflow.com/questions/309834/should-i-commit-or-rollback-a-read-transaction">Should I commit or rollback a read transaction?</a></p>
  
  <p><strong>EDIT (Clarification of Question):</strong></p>
  
  <p>Not looking for advice up to point of commit/rollback.  Transaction is absolutely necessary.  Assume no errors occur.  Assume I have created a temp table, assume I know real "work" writing to tempdb has occurred, assume I perform read-only (select) operations in the transaction, and assume I issue a delete statement on the temp table.  After all that... which is cheaper, commit or rollback, and why?  What OTHER work might the db engine do at THAT POINT for a commit vs a rollback, based on this specific scenario involving temp-tables and otherwise read-only operations?</p>