# Towards 14,000 write transactions per second on my laptop

DevFeed: [Towards 14,000 write transactions per second on my laptop](<https://devfeed.tech/articles/towards-14-000-write-transactions-per-second-on-my-laptop-33643.md>)

Original publisher: [Read original article](<https://pgeoghegan.blogspot.com/2012/06/towards-14000-write-transactions-on-my.html>)

Author: Peter Geoghegan (noreply@blogger.com)

Published: 2012-06-04T18:00:00Z

Content type: article

Language: en

Sources: [Peter Geoghegan's blog](<https://devfeed.tech/sources/peter-geoghegan-s-blog.md>)

Topics: [Transactions](<https://devfeed.tech/topics/transactions.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [backends](<https://devfeed.tech/topics/backends.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [Latency](<https://devfeed.tech/topics/latency.md>)

Tags: [backends](<https://devfeed.tech/tags/backends.md>), [batching](<https://devfeed.tech/tags/batching.md>), [benchmark](<https://devfeed.tech/tags/benchmark.md>), [c](<https://devfeed.tech/tags/c.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [queue](<https://devfeed.tech/tags/queue.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [time](<https://devfeed.tech/tags/time.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

## AI overview

The article explains a Postgres 9.2 performance improvement for small write transactions. By reducing contention around WALWriteLock and batching commit-related WAL flushes, the change increases throughput without adding arbitrary commit latency or requiring additional configuration.

## Source excerpt

Postgres 9.2 will have many improvements to both read and write scalability. Simon Riggs and I collaborated on a performance feature that greatly increased the throughput of small write transactions. Essentially, it accomplishes this by reducing the lock contention surrounding an internal lock called WALWriteLock. When an individual backend/connection holds this lock, it is empowered to write WAL from wal_buffers, an area of shared memory that temporarily holds WAL until it is written, and ultimately flushed to persistent storage. Original update.sql "new group commit" benchmark, January 2012. This made it into Postgres 9.2. Here, we compare the performance of my original patch (red line) and Postgres master in January (green line). 9.1 performance on this benchmark would probably be very similar to that of the baseline seen here. With this patch, we don't have the backends queue up for the WALWriteLock to write their WAL as before. Rather, they either immediately obtain the WALWriteLock, or else queue up for it. However, when the lock becomes available, no waiting backend actually immediately acquires the lock. Rather, each backend once again checks if WAL has been flushed up to the LSN that the transaction being committed needs to be flushed up to. Oftentimes, they will find that this has happened, and will be able to simply fastpath out of the function that ensures that WAL is flushed (a call to that function is required to honour transactional semantics). In fact, it is expected that only a small minority of backends (one at a time, dubbed "the leader") will actually ever go through with flushing WAL. In this manner, we batch commits, resulting in a really large increase in throughput, as you can tell from the diagram above. In Postgres 9.2, this improvement automatically becomes available without any further configuration. This was one of the subjects of my recent talk, co-presented with Greg Smith at PgCon 2012, "A Batch of Commit Batching". There is some conf