Postgresql on Ivan Luminaria

VACUUM și autovacuum: de ce PostgreSQL are nevoie ca cineva să facă curățenie

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

Acum câțiva ani mi s-a cerut să verific un PostgreSQL în producție care “se încetinește în fiecare săptămână”. Mereu același tipar: luni merge bine, vineri e dezastru. În weekend cineva repornește serviciul și se începe de la capăt.

Baza de date de aproximativ 200 GB. Tabelele principale ocupau aproape triplul spațiului efectiv al datelor. Query-uri care cădeau în sequential scan acolo unde nu ar fi trebuit. Timpii de răspuns creșteau zi de zi.

Roluri și utilizatori în PostgreSQL: de ce totul este (doar) un ROLE

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

Prima dată când am lucrat serios cu PostgreSQL veneam după ani de experiență cu alte baze de date. Căutam comanda CREATE USER. O găseam. Apoi vedeam CREATE ROLE. Apoi ALTER USER. Apoi ALTER ROLE.
Pentru câteva minute am gândit: „Bine, aici cineva se distrează încurcând lumea.”

În realitate, nu. PostgreSQL este mult mai coerent decât pare. Doar că este coerent în felul lui.

În PostgreSQL nu există utilizatori. Există roluri. #

Cheia este aceasta: în PostgreSQL totul este un ROLE.

Când un LIKE '%valoare%' încetinește totul: un caz real de optimizare PostgreSQL

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

Cu câteva săptămâni în urmă, un client m-a contactat cu o problemă foarte comună:

“Căutarea din consola administrativă este lentă. Uneori durează câteva secunde. Am redus deja JOIN-urile, dar problema nu a dispărut.”

Mediu: PostgreSQL în cloud managed.
Tabela principală: payment_report (~6 milioane de rânduri, 3 GB).
Coloana căutată: reference_code.

Query problematic:

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 observație: JOIN-urile nu erau problema #

Am comparat:

EXPLAIN ANALYZE nu e suficient: cum sa citesti cu adevarat un plan de executie PostgreSQL

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

Zilele trecute un coleg imi trimite o captura de ecran pe Teams. Un query care ruleaza pe o tabela de 2 milioane de randuri, 45 de secunde timp de executie. Imi scrie:

“Am facut EXPLAIN ANALYZE, dar nu inteleg ce e in neregula. Planul pare corect.”

Spoiler: planul nu era deloc corect. Optimizatorul alesese un nested loop join unde era nevoie de un hash join , iar motivul era banal — statistici neactualizate. Dar ca sa ajung acolo a trebuit sa citesc planul rand cu rand, si atunci mi-am dat seama ca majoritatea DBA-ilor pe care ii cunosc folosesc EXPLAIN ANALYZE ca pe un oracol binar: daca timpul e mare, query-ul e lent. Sfarsitul analizei.