aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMartin Kagamino Lehoux <martin@lehoux.net>2026-03-29 16:50:55 +0200
committerMartin Kagamino Lehoux <martin@lehoux.net>2026-03-29 16:54:41 +0200
commit976950808051a214049adf41009878eeb8e13920 (patch)
tree8de0ed9e6decf01c5282a4c9670ba623bd1e7beb
parent27904361fc944ad66ced65cf4b4558460c5a275a (diff)
Cross linking
-rw-r--r--content/posts/postgres-aggregates/index.md4
1 files changed, 3 insertions, 1 deletions
diff --git a/content/posts/postgres-aggregates/index.md b/content/posts/postgres-aggregates/index.md
index a2ff276..cf7a977 100644
--- a/content/posts/postgres-aggregates/index.md
+++ b/content/posts/postgres-aggregates/index.md
@@ -2,12 +2,14 @@
title: "Efficient PostgreSQL Aggregations"
draft: false
date: 2023-10-04
-lastmod: 2024-07-15
+lastmod: 2026-03-29
description: "Diving into PostgreSQL query plans to improve our tooling"
categories:
- PostgreSQL
---
+> This article [has a follow-up](/posts/postgres-aggregates-correction/), where I fix a mistake in the subquery benchmarks and explore disk usage under production-like constraints.
+
I recently stumbled upon a problem while crafting queries for PostgreSQL at work. We had a query with several correlated subqueries that was becoming too slow for the intended use (a search). I thought that using aggregations would solve it, but in fact it slowed it down, and even added bugs from counting duplicate rows.
I couldn't find easily accessible knowledge about how to improve it on the Internet, so I decided to simplify the problem to its core and to investigate. This article is the walkthrough of my findings.