Administrace komentářů

Tak zacit muzes jiste tim ze se konecne podivas jestli ten procesor drti PHP nebo Postgres, skoro me to zacina zajimat. Zkus se na ten top podivat poradne a nestyd se nam to tajemstvi vyjevit.

Kdyz uz mas povolene ty statistiky, tak se pojdme podivat, jestli nekde nemuzeme pojmout podezreni, ze chybi index. To udelame tak, ze so podivame nad jakymi tabulkami se dela vic sekvencnich scanu, nez kolikrat se pouziva index scan:

SELECT relname, seq_scan-idx_scan AS too_much_seq, CASE WHEN seq_scan-idx_scan>0 THEN 'Missing Index?' ELSE 'OK' END, seq_scan, idx_scan FROM pg_stat_all_tables WHERE schemaname='public'  ORDER BY too_much_seq DESC;

Ma to samozrejme vady - 1) ne vzdycky je sekvencni scan spatne - Kdyz si to uplne zjednodusime, cim mensi tabulka, tim min vadi, az je rychlejsi nez index a 2) ze tady vypada tabulka "dobre", neznamena, ze se s ni vsude pracuje velmi a spravne, jen dotazy z homepage potrebuji ten sekvencni scan a trvaji dlouho. Poucka: U tech tabulek co vypadnou jako podezrele se podivej na velikost, kdyz velke, (mozna) spatne.

Nezapomen, ze ten dotaz, tak jak je napsan, se diva jen na tabulky z public schema, pokud pouzivate pro tu databazi co nezname jine, musis ho nalezite upravit.

Taky nezapomen, ze ta aplikace bezi, v tech statistikach zdaleka nemas jen data od dotazu generovanych strankou, ktera te zajima.

Kdyz uz v tom budes, muzes se jiste cvicne podivat, jestli ti taky nejake indexy neprebyvaji, coz muze zpomalovat zapis (Pokud te chapu, je to nejaka homepage, takze toho asi moc nezapisuje a tohle je nam jedno, ale co uz, aspon uvidime, jak moc to vyvojari resi)

SELECT indexrelid::regclass as index, relid::regclass as table, 'DROP INDEX ' || indexrelid::regclass || ';' as drop_statement FROM pg_stat_user_indexes JOIN pg_index USING (indexrelid) WHERE idx_scan = 0 AND indisunique is false;

A sice jsem to povazoval za samozrejmost, ale zminit se to musi - ma ten Postgres zapnute autovacuum nebo je implementovano neco co dela neco periodicky vacuum? Pokud "nevim", zjistit, pokud ne, implementovat. Pokud se ty data meni, bez vacuum se ta databaze s casem zpomaluje az do uplne nepouzitenosti.

Az se probereme timhle, a budes mit pripravene k pouziti pg_stats_statements podle prislusne jedne stranky dokumentace, kterou si jiste prectes az do konce a uz me nebudes potrebovat, postoupime k pouziti, to pak bude teprve u vyvojaru zabava.

To ze jsi systemak a ne "db expert" je jedno, garantuju ze nic expertniho nedelame a delat ani nebudeme.