<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>SQL on Clément Sauvage</title><link>https://www.clemsau.com/tags/sql/</link><description>Recent content in SQL on Clément Sauvage</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 Clément Sauvage</copyright><lastBuildDate>Thu, 07 May 2026 08:52:42 +0000</lastBuildDate><atom:link href="https://www.clemsau.com/tags/sql/index.xml" rel="self" type="application/rss+xml"/><item><title>How OR clauses were silently killing our query performance</title><link>https://www.clemsau.com/posts/how-or-clauses-were-silently-killing-our-query-performance/</link><pubDate>Thu, 07 May 2026 08:52:42 +0000</pubDate><guid>https://www.clemsau.com/posts/how-or-clauses-were-silently-killing-our-query-performance/</guid><description>&lt;p&gt;Recently at work (on my last day), I dealt with a SQL query that got pretty complex because of new features making the business logic increasingly involved. The query ended up quite lengthy, but it was still the best way to respond to the new requirements. We were iterating over rows in a PostgreSQL database by batches across 20 parallel goroutines, until all rows had been processed.&lt;/p&gt;</description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://www.clemsau.com/posts/how-or-clauses-were-silently-killing-our-query-performance/feature.jpg"/></item></channel></rss>