Performance 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.

Oracle on Linux: the kernel parameters nobody configures

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

The client was a logistics company running Oracle 19c Enterprise Edition on Oracle Linux 8. Sixty concurrent users, a custom ERP application, about 400 GB of data. The server was a Dell PowerEdge with 128 GB of RAM and 32 cores.

The complaints were vague but persistent: “The system is slow.” “Morning queries take twice as long as two months ago.” “Every now and then everything freezes for a few seconds.”

AWR, ASH and the 10 minutes that saved a go-live

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

Friday, 6:40 PM. I already had my jacket on, ready to leave. The phone buzzes. It’s the project manager.

“Ivan, we have a problem. The system is crawling. The go-live is tomorrow morning.”

It’s not the first time I’ve received a call like that. But the tone was different. This wasn’t the usual vague complaint about slowness. This was panic.

I reconnect to the VPN, open a session on the client’s Oracle 19c database. First thing I do is a quick check:

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:

Oracle Partitioning: when 2 billion rows no longer fit in a query

Tue, 23 Dec 2025 08:03:00 +0100

Two billion rows. You do not reach that number in a day. It takes years of transactions, movements, daily records piling up. And for all that time the database works, queries respond, reports come out. Then one day someone opens a ticket: “the monthly report takes four hours.”

Four hours. For a report that six months earlier took twenty minutes.

It is not a bug. It is not a network issue or slow storage. It is the physics of data: when a table grows beyond a certain threshold, the approaches that worked stop working. And if you did not design the structure to handle that growth, the database does the only thing it can: read everything.

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.