title: Why are my COMMITs after SELECT-only transactions slow with PostgreSQL?
body: <p>I have a web app presenting data that's being generated by a separate process and stored in PostgreSQL, version 8.4. The backend is writing fairly continuously, but the majority of views in the web app execute nothing but read-only SELECT queries.</p>
  
  <p>According to the New Relic Python agent, 30% of my view processing time is spent waiting for COMMITs to complete, and it's particularly bad in views that issued a lot of SELECT queries, even if they didn't modify any data.</p>
  
  <p>I expected a transaction that had been read-only to have very little work to do during the commit phase. What is Postgres doing during COMMIT on these read-only queries?</p>
  
  <p>I know I could turn off <code>synchronous_commit</code> for these transactions to hide the latency from the view, and I certainly don't care about durability for a read-only transaction, but I don't see why it should be necessary, and I'm concerned that doing so might mask a deeper misconfiguration.</p>