When a LIKE '%value%' Slows Everything Down: A Real PostgreSQL Optimization Case

Tue, 06 Jan 2026 08:03:00 +0100

A few weeks ago, a client contacted me with a very common issue:

“Search in the admin console is slow. Sometimes it takes several seconds. We’ve already reduced the JOINs, but the problem hasn’t disappeared.”

Environment: PostgreSQL on managed cloud.
Main table: payment_report (~6 million rows, 3 GB).
Searched column: reference_code.

Problematic query:

SELECT *
FROM reporting.payment_report r
JOIN reporting.payment_cart c ON c.id = r.cart_id
WHERE c.service_id = 1001
 AND r.reference_code LIKE '%ABC123%'
ORDER BY c.created_at DESC
LIMIT 100;

🧠 First observation: the JOINs were not the problem #

I compared:

EXPLAIN ANALYZE is not enough: how to actually read a PostgreSQL execution plan

Tue, 28 Oct 2025 08:03:00 +0100

The other day a colleague sends me a screenshot on Teams. A query running on a 2-million-row table, 45 seconds execution time. He writes:

“I ran EXPLAIN ANALYZE, but I can’t figure out what’s wrong. The plan looks fine.”

Spoiler: the plan was anything but fine. The optimizer had chosen a nested loop join where a hash join was needed, and the reason was trivial — stale statistics. But to get there I had to read the plan line by line, and that’s when I realized that most DBAs I know use EXPLAIN ANALYZE as a binary oracle: if the time is high, the query is slow. End of analysis.

Query-Tuning on Ivan Luminaria

When a LIKE '%value%' Slows Everything Down: A Real PostgreSQL Optimization Case

🧠 First observation: the JOINs were not the problem #

EXPLAIN ANALYZE is not enough: how to actually read a PostgreSQL execution plan