Performance on Ivan Luminaria

VACUUM e autovacuum: perché PostgreSQL ha bisogno che qualcuno pulisca

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

Un paio d’anni fa mi chiedono di guardare un PostgreSQL in produzione che “rallenta ogni settimana”. Sempre lo stesso pattern: lunedì va bene, venerdì è un disastro. Il weekend qualcuno riavvia il servizio e si ricomincia.

Database da circa 200 GB. Tabelle principali che occupavano quasi il triplo dello spazio effettivo dei dati. Query che andavano in sequential scan su tabelle dove non avrebbero dovuto. Tempi di risposta che salivano di giorno in giorno.

Oracle su Linux: i parametri kernel che nessuno configura

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

Il cliente era una società di logistica con un Oracle 19c Enterprise Edition su Oracle Linux 8. Sessanta utenti concorrenti, un gestionale custom, circa 400 GB di dati. Il server era un Dell PowerEdge con 128 GB di RAM e 32 core.

Le lamentele erano vaghe ma persistenti: “Il sistema è lento.” “Le query del mattino ci mettono il doppio rispetto a due mesi fa.” “Ogni tanto si blocca tutto per qualche secondo.”

AWR, ASH e i 10 minuti che hanno salvato un go-live

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

Venerdì, ore 18:40. Ero già con il giubbotto addosso, pronto per uscire. Il telefono vibra. È il project manager.

“Ivan, abbiamo un problema. Il sistema è lentissimo. Domani mattina c’è il go-live.”

Non è la prima volta che ricevo una chiamata del genere. Ma il tono era diverso dal solito. Non era la lamentela generica sulla lentezza. Era panico.

Mi ricollego in VPN, apro una sessione sul database Oracle 19c del cliente. La prima cosa che faccio è un controllo rapido:

Quando un LIKE '%valore%' rallenta tutto: un caso reale di ottimizzazione PostgreSQL

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

Qualche settimana fa un cliente mi contatta con un problema molto comune:

“La ricerca nella console amministrativa è lenta. A volte impiega diversi secondi. Abbiamo già ridotto le JOIN, ma il problema non è sparito.”

Ambiente: PostgreSQL su cloud managed.
Tabella principale: payment_report (~6 milioni di righe, 3 GB).
Colonna ricercata: reference_code.

Query incriminata:

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;

🧠 Prima osservazione: il problema non erano le JOIN #

Ho confrontato:

Oracle Partitioning: quando 2 miliardi di righe non entrano più in una query

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

Due miliardi di righe. Non è un numero che si raggiunge in un giorno. Ci vogliono anni di transazioni, di movimenti, di registrazioni quotidiane che si accumulano. E per tutto quel tempo il database funziona, le query rispondono, i report escono. Poi un giorno qualcuno apre un ticket: “il report mensile ci mette quattro ore.”

Quattro ore. Per un report che sei mesi prima ne impiegava venti minuti.

Non è un bug. Non è un problema di rete o di storage lento. È la fisica dei dati: quando una tabella cresce oltre una certa soglia, gli approcci che funzionavano smettono di funzionare. E se non hai progettato la struttura per gestire quella crescita, il database fa l’unica cosa che può fare: leggere tutto.

EXPLAIN ANALYZE non basta: come leggere davvero un piano di esecuzione PostgreSQL

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

L’altro giorno un collega mi manda uno screenshot su Teams. Una query che gira su una tabella da 2 milioni di righe, 45 secondi di esecuzione. Mi scrive:

“Ho fatto EXPLAIN ANALYZE, ma non capisco cosa c’è che non va. Il piano sembra corretto.”

Spoiler: il piano non era affatto corretto. L’optimizer aveva scelto un nested loop join dove serviva un hash join , e la ragione era banale — statistiche non aggiornate. Ma per arrivarci ho dovuto leggere il piano riga per riga, e lì mi sono reso conto che la maggior parte dei DBA che conosco usa EXPLAIN ANALYZE come un oracolo binario: se il tempo è alto, la query è lenta. Fine dell’analisi.