Markus Schaber <schabi@xxxxxxxxxxxx> writes: > Some time ago, I had some tests with large bulk insertions, and it > turned out that SERIALIZABLE seemed to be 30% faster, which surprised us. That surprises me too --- can you provide details on the test case so other people can reproduce it? AFAIR the only performance difference between SERIALIZABLE and READ COMMITTED is the frequency with which transaction status snapshots are taken; your report suggests you were spending 30% of the time in GetSnapshotData, which is a lot higher than I've ever seen in a profile. As to the original question, a transaction that hasn't modified the database does not bother to write either a commit or abort record to pg_xlog. I think you'd be very hard pressed to measure any speed difference between saying COMMIT and saying ROLLBACK after a read-only transaction. It'd be worth your while to let transactions run longer to minimize their startup/shutdown overhead, but there's a point of diminishing returns --- you don't want client code leaving transactions open for hours, because of the negative side-effects of holding locks that long (eg, VACUUM can't reclaim dead rows). regards, tom lane
