Jak sprawdzic obciazenie bazy danych postgresql?

Odpowiedz Nowy wątek
2019-01-03 12:15
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?

Pozostało 580 znaków

2019-01-03 12:39
1

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

siee spóźniłem - mr_jaro 2019-01-03 12:42

Pozostało 580 znaków

2019-01-03 12:40
2

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

Pozostało 580 znaków

2019-01-03 13:24
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ć

Sprawdzilem i nie ma poblokowanych transakcji. Zaraz sprawdze vacuum ( cokolwiek to jest :D ). - poniatowski 2019-01-03 13:33
Nie vacuum, tylko autovacuum. Nad tym pierwszym panujesz, nad drugim nie. - Marcin.Miga 2019-01-03 13:50

Pozostało 580 znaków

2019-01-03 13:35
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.

Pozostało 580 znaków

2019-01-03 13:45
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);

?

Pozostało 580 znaków

2019-01-03 13:50
2

ten drugi

Czyli indexy zakladamy tylko jak dana kolumna wystepuje w laczeniach join albo warunkach? - poniatowski 2019-01-03 13:58
Tak nie do końca, ale generalnie tak. Nie nalezy też przesadzać z ilością indeksów, bo każdy INSERT i UPDATE mogą wtedy trwać wieki. Indeksy są przydatne do tylko do SELECT - Marcin.Miga 2019-01-03 14:02

Pozostało 580 znaków

2019-01-03 13:56
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...

Jak moge sprawdzic czy baza danych cachuje moje zapytanie? - poniatowski 2019-01-03 16:23

Pozostało 580 znaków

2019-01-03 13:58
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 :-)

Pozostało 580 znaków

2019-01-03 14:32
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


Chcesz pomocy - pokaż kod - abrakadabra źle działa z techniką.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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