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

Oracle pe Linux: parametrii kernel pe care nimeni nu-i configurează

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

Clientul era o companie de logistică cu Oracle 19c Enterprise Edition pe Oracle Linux 8. Șaizeci de utilizatori concurenți, o aplicație ERP personalizată, circa 400 GB de date. Serverul era un Dell PowerEdge cu 128 GB de RAM și 32 de core-uri.

Plângerile erau vagi dar persistente: “Sistemul e lent.” “Query-urile de dimineață durează dublu față de acum două luni.” “Din când în când se blochează totul câteva secunde.”

Când m-am conectat pe server, primul lucru pe care l-am verificat nu a fost baza de date. A fost sistemul de operare.

AWR, ASH și cele 10 minute care au salvat un go-live

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

Vineri, ora 18:40. Aveam deja geaca pe mine, gata de plecare. Telefonul vibrează. E project managerul.

“Ivan, avem o problemă. Sistemul merge foarte lent. Mâine dimineață e go-live-ul.”

Nu e prima dată când primesc un astfel de apel. Dar tonul era diferit. Nu era plângerea obișnuită despre lentoare. Era panică.

Mă reconectez prin VPN, deschid o sesiune pe baza de date Oracle 19c a clientului. Primul lucru pe care îl fac e o verificare rapidă:

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:

Oracle Partitioning: când 2 miliarde de rânduri nu mai încap într-o interogare

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

Două miliarde de rânduri. Nu este un număr la care ajungi într-o zi. Durează ani de tranzacții, mișcări, înregistrări zilnice care se acumulează. Și în tot acest timp baza de date funcționează, interogările răspund, rapoartele ies. Apoi într-o zi cineva deschide un ticket: „raportul lunar durează patru ore."

Patru ore. Pentru un raport care cu șase luni înainte dura douăzeci de minute.

Nu este un bug. Nu este o problemă de rețea sau de stocare lentă. Este fizica datelor: când o tabelă crește peste un anumit prag, abordările care funcționau nu mai funcționează. Și dacă nu ai proiectat structura să gestioneze acea creștere, baza de date face singurul lucru pe care îl poate face: citește totul.

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.