Jak sprawdzic obciazenie bazy danych postgresql?

Witam,

Mam kilka zapytan SQL, ktore raz wykonuja sie w 2-3 sek. Innym razem 2-3 minuty. A zapytanie jest to samo, wyciaga 10 000 zamowien. Jak moge sprawdzic czemu tak sie dzieje?

pgAdmin 3 -> SHIFT F7
lub EXPLAIN (ANALYZE on, VERBOSE on, COSTS on, BUFFERS off, TIMING on ) zapytanie

może to pomoże https://www.postgresql.org/docs/9.2/using-explain.html

A właśnie. zapomniałem dodać, że jeszcze może być kwetsia tego, że autovacuum się robią na tabelach... albo tabele sa blokowane innymi transakcjami... Wiele czynników może być

Zalozylem wielokrotny ideks i zapytanie wykonuje sie znacznie szybciej. Indeks jest na 3 kolumny. I wykonuje sie conajmniej 10 razy szybciej. Przeanalizowalem jeszcze z EXPLAIN, zeby byc pewnym, ze indeks jest uzyty i jest. Dzieki. Przeczytam jeszcze caly ten art o EXPLAIN, bo szczerze nie mam pewnosci, ze dobrze czytam wyrzucone wyniki z EXPLAIN.

Jesczcze jedno pytanie:

SELECT email, first_name, last_name, activated
FROM users
WHERE removed IS NULL AND activated > NOW() - INTERVAL '30 days';

Jak poprawnie zalozyc INDEX na przykladowe zapytanie powyzej?

CREATE INDEX idx_users ON ac_user (email, first_name, last_name, activated, removed);

czy

CREATE INDEX idx_users ON ac_user (activated, removed);

?

ten drugi

Jeszcze pamietaj ze baza potrafi sobie cachowac rozne rzeczy wiec jak pytasz pare razy pod rzad, pierwsza odpowiedz moze trwac dlugo albo bardzo dlugo a nastepne beda szybkie...

Postgres ma taki wynalazek jak indeks częściowy, może tak:

CREATE INDEX idx_users ON ac_user (activated) WHERE removed IS NULL;

Nie chce mi się sprawdzać czy postgres domyślnie indeksuje nulle :-)

poniatowski napisał(a):

CREATE INDEX idx_users ON ac_user (email, first_name, last_name, activated, removed);

jeśli już to w tym konkretnym wypadku powinno być

CREATE INDEX idx_users ON ac_user (activated, removed, email, first_name, last_name);

najpierw kolumny, które są w warunku (po nich baza filtruje) a potem kolumny, które chcesz zwrócić (wtedy baza nie musi "zaglądać" do tabeli bo wszystkie dane ma w indeksie). Jednak jak pisali poprzednicy, dużo wielokolumnowych indeksów to zabójstwo dla wydajności przy insert/update