<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>PostgreSQL on Software Engineering &amp; Personal Thoughts</title><link>https://getpid.dev/tags/postgresql/</link><description>Recent content in PostgreSQL on Software Engineering &amp; Personal Thoughts</description><generator>Hugo -- 0.147.2</generator><language>en-us</language><lastBuildDate>Wed, 02 Sep 2026 16:00:00 +0200</lastBuildDate><atom:link href="https://getpid.dev/tags/postgresql/index.xml" rel="self" type="application/rss+xml"/><item><title>Atomic Database Operations</title><link>https://getpid.dev/blog/atomic-database-operations/</link><pubDate>Wed, 02 Sep 2026 16:00:00 +0200</pubDate><guid>https://getpid.dev/blog/atomic-database-operations/</guid><description>&lt;p>Today we will explore how to leverage atomic operations without opening a multi-statement transaction,
increasing the system&amp;rsquo;s write throughput without sacrificing correctness.&lt;/p>
&lt;p>To avoid conflicts with other processes changing the same data, we can lock the rows before
updating them, for example with &lt;code>SELECT ... FOR UPDATE&lt;/code>.
This approach has drawbacks: locks consume database resources for the entire duration of the
transaction and can lead to lock contention as writers wait for one another, reducing write throughput.
It is generally preferable for transactions to be short.&lt;/p></description></item></channel></rss>