Jak sprawdzic obciazenie bazy danych postgresql?

0

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?

1

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

1

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ć

0

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.

0

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);

?

2

ten drugi

1

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

1

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 :-)

2
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

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0