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

Ruoli e utenti in PostgreSQL: perché è tutto (solo) un ROLE

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

La prima volta che ho lavorato seriamente con PostgreSQL arrivavo da anni di altri database. Cercavo il comando CREATE USER. Lo trovavo. Poi vedevo CREATE ROLE. Poi ALTER USER. Poi ALTER ROLE.
Per qualche minuto ho pensato: “Ok, qui qualcuno si diverte a confondere le persone”.

In realtà no. PostgreSQL è molto più coerente di quanto sembri. Solo che lo è a modo suo.

In PostgreSQL non esistono utenti. Esistono ruoli. #

La chiave è questa: in PostgreSQL tutto è un ROLE.

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:

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.