PostgreSQL on Ivan Luminaria

VACUUM and autovacuum: why PostgreSQL needs someone to clean up

Tue, 24 Mar 2026 08:03:00 +0100

A couple of years ago I was asked to look at a production PostgreSQL instance that “slows down every week”. Always the same pattern: Monday is fine, Friday is a disaster. Someone restarts the service over the weekend and the cycle starts again.

Database around 200 GB. Main tables occupying nearly three times their actual data size. Queries falling into sequential scans where they shouldn’t have been. Response times climbing day after day.

Roles and Users in PostgreSQL: Why Everything Is (Only) a ROLE

Tue, 10 Feb 2026 08:03:00 +0100

The first time I seriously worked with PostgreSQL I was coming from years of other databases. I looked for the CREATE USER command. I found it. Then I saw CREATE ROLE. Then ALTER USER. Then ALTER ROLE.
For a few minutes I thought: “Alright, someone here enjoys confusing people.”

Actually, no. PostgreSQL is far more consistent than it appears. It is just consistent in its own way.

In PostgreSQL there are no users. There are roles. #

The key is this: in PostgreSQL everything is a ROLE.

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.