Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
PostgreSQL - jak interpretować explain w celu diagnostyki?
164 views
Skip to first unread message
Marek S
Apr 4, 2018, 2:53:58 PM4/4/18
to
Witam,
Miałem właśnie przypadek dość złożonego zapytania SQL. Select pracował
ze 20 minut. Próbowałem zapuścić Explain na tym zapytaniu w PGadminie.
Powstały jakieś blokowe schemaciki zawierające dane jak koszt itp.
Szczerze mówiąc - nie mam bladego pojęcia jak z tego wyciągnąć
jakiekolwiek wnioski i ustalić przyczynę, dla której zapytanie tyle
czasu wykonywało się. Faktem jest, że rekordów było kilkaset tysięcy,
parę Joinów i innych konstrukcji multiplikujących tę ilość.
Poddałem się z Explainem. Podzieliłem zapytanie na mniejsze fragmenty by
odszukać winowajcę. Tak namierzyłem tabelę, w której ktoś... nie założył
indeksów na klucze obce... Czas realizacji po ich założeniu: 0.5s.
Patrzę na Explaina dla wersji z indeksami i szczerze mówiąc nie widzę
jakiś różnic a w czasie wykonywania jest ogromna.
Czytałem instrukcję do bazy na w/w temat. Opis jest taki jakby sami
twórcy nie bardzo wiedzieli co z tym zrobić praktycznego.
A może nie tak diagnostyka powinna wyglądać?
--
Pozdrawiam,
Marek
Miałem właśnie przypadek dość złożonego zapytania SQL. Select pracował
ze 20 minut. Próbowałem zapuścić Explain na tym zapytaniu w PGadminie.
Powstały jakieś blokowe schemaciki zawierające dane jak koszt itp.
Szczerze mówiąc - nie mam bladego pojęcia jak z tego wyciągnąć
jakiekolwiek wnioski i ustalić przyczynę, dla której zapytanie tyle
czasu wykonywało się. Faktem jest, że rekordów było kilkaset tysięcy,
parę Joinów i innych konstrukcji multiplikujących tę ilość.
Poddałem się z Explainem. Podzieliłem zapytanie na mniejsze fragmenty by
odszukać winowajcę. Tak namierzyłem tabelę, w której ktoś... nie założył
indeksów na klucze obce... Czas realizacji po ich założeniu: 0.5s.
Patrzę na Explaina dla wersji z indeksami i szczerze mówiąc nie widzę
jakiś różnic a w czasie wykonywania jest ogromna.
Czytałem instrukcję do bazy na w/w temat. Opis jest taki jakby sami
twórcy nie bardzo wiedzieli co z tym zrobić praktycznego.
A może nie tak diagnostyka powinna wyglądać?
--
Pozdrawiam,
Marek
artiun
Apr 4, 2018, 4:22:55 PM4/4/18
to
W dniu 2018-04-04 o 20:53, Marek S pisze:
integralność danych (awaria dysku itp.) Postgresql ma zabezpieczenia, no
chyba, że dysk padł i nie ma gdzie zrzucić danych (plików)
Nie sądzę.
--
Artur
> Witam,
>
> Miałem właśnie przypadek dość złożonego zapytania SQL. Select pracował ze 20
> minut. Próbowałem zapuścić Explain na tym zapytaniu w PGadminie. Powstały
> jakieś blokowe schemaciki zawierające dane jak koszt itp. Szczerze mówiąc -
> nie mam bladego pojęcia jak z tego wyciągnąć jakiekolwiek wnioski i ustalić
> przyczynę, dla której zapytanie tyle czasu wykonywało się. Faktem jest, że
> rekordów było kilkaset tysięcy, parę Joinów i innych konstrukcji
> multiplikujących tę ilość.
Też nie wiem (20 min to dziwne, mało, że dziene)... Duza kropa. Pierwsze,
>
> Miałem właśnie przypadek dość złożonego zapytania SQL. Select pracował ze 20
> minut. Próbowałem zapuścić Explain na tym zapytaniu w PGadminie. Powstały
> jakieś blokowe schemaciki zawierające dane jak koszt itp. Szczerze mówiąc -
> nie mam bladego pojęcia jak z tego wyciągnąć jakiekolwiek wnioski i ustalić
> przyczynę, dla której zapytanie tyle czasu wykonywało się. Faktem jest, że
> rekordów było kilkaset tysięcy, parę Joinów i innych konstrukcji
> multiplikujących tę ilość.
integralność danych (awaria dysku itp.) Postgresql ma zabezpieczenia, no
chyba, że dysk padł i nie ma gdzie zrzucić danych (plików)
>
> Poddałem się z Explainem. Podzieliłem zapytanie na mniejsze fragmenty by
> odszukać winowajcę. Tak namierzyłem tabelę, w której ktoś... nie założył
> indeksów na klucze obce... Czas realizacji po ich założeniu: 0.5s.
>
Jeśli jest jw. to nic nie pomoże
> Poddałem się z Explainem. Podzieliłem zapytanie na mniejsze fragmenty by
> odszukać winowajcę. Tak namierzyłem tabelę, w której ktoś... nie założył
> indeksów na klucze obce... Czas realizacji po ich założeniu: 0.5s.
>
> Patrzę na Explaina dla wersji z indeksami i szczerze mówiąc nie widzę jakiś
> różnic a w czasie wykonywania jest ogromna.
>
> Czytałem instrukcję do bazy na w/w temat. Opis jest taki jakby sami twórcy
> nie bardzo wiedzieli co z tym zrobić praktycznego.
>
> A może nie tak diagnostyka powinna wyglądać?
>
Skończyło się to?
> różnic a w czasie wykonywania jest ogromna.
>
> Czytałem instrukcję do bazy na w/w temat. Opis jest taki jakby sami twórcy
> nie bardzo wiedzieli co z tym zrobić praktycznego.
>
> A może nie tak diagnostyka powinna wyglądać?
>
Nie sądzę.
--
Artur
irq
Apr 5, 2018, 6:14:47 AM4/5/18
to
Może spróbuj tutaj: https://explain.depesz.com/
Na samym blogu depesza znajdziesz też cykl wpisów o EXPLAIN, to pierwszy z nich: https://www.depesz.com/2013/04/16/explaining-the-unexplainable/
Na samym blogu depesza znajdziesz też cykl wpisów o EXPLAIN, to pierwszy z nich: https://www.depesz.com/2013/04/16/explaining-the-unexplainable/
Roman Tyczka
Apr 5, 2018, 6:37:45 AM4/5/18
to
Usuń indeks, jeszcze raz zrób explain (ale z klauzulą analyze) i pokaż
plan.
--
pozdrawiam
Roman Tyczka
Marek S
Apr 5, 2018, 4:41:24 PM4/5/18
to
W dniu 2018-04-04 o 22:20, artiun pisze:
do 0.5s czyli rewelacyjnie. Dlaczego nie sądzisz, że dodanie brakujących
indeksów na kluczach obcych nie mogło pomóc?
--
Pozdrawiam,
Marek
>>
> Skończyło się to?
> Nie sądzę.
Nooo... tak jak napisałem. Po założeniu indeksów czas realizacji spadł
> Skończyło się to?
> Nie sądzę.
do 0.5s czyli rewelacyjnie. Dlaczego nie sądzisz, że dodanie brakujących
indeksów na kluczach obcych nie mogło pomóc?
--
Pozdrawiam,
Marek
Marek S
Apr 5, 2018, 4:45:59 PM4/5/18
to
W dniu 2018-04-05 o 12:14, irq pisze:
To jest to samo co Postgres robi bez graficznej reprezentacji narzucanej
przez Pgadmina. Tak więc niczego więcej tu się nie dowiem ... w
odróżnieniu od poniższego :-)
> Na samym blogu depesza znajdziesz też cykl wpisów o EXPLAIN, to pierwszy z nich: https://www.depesz.com/2013/04/16/explaining-the-unexplainable/
>
Bardzo dobra informacja! Dzięki :-)
--
Pozdrawiam,
Marek
To jest to samo co Postgres robi bez graficznej reprezentacji narzucanej
przez Pgadmina. Tak więc niczego więcej tu się nie dowiem ... w
odróżnieniu od poniższego :-)
> Na samym blogu depesza znajdziesz też cykl wpisów o EXPLAIN, to pierwszy z nich: https://www.depesz.com/2013/04/16/explaining-the-unexplainable/
>
--
Pozdrawiam,
Marek
Marek S
Apr 5, 2018, 4:50:49 PM4/5/18
to
W dniu 2018-04-05 o 12:37, Roman Tyczka pisze:
>
> Na 100% wynik explaina był inny przed i po indeksach.
> Usuń indeks, jeszcze raz zrób explain (ale z klauzulą analyze) i pokaż
> plan.
Faktem jest, że za dużo było tam nic nie mówiących informacji. Z Analyze
nie robiłem Niestety nie mogę się bawić z tamtą bazą - to żywy organizm.
Moim zadaniem było naprawić problem i to się udało. Spróbuję w wolnej
chwili potrenować na jakiejś bazie na boku.
--
Pozdrawiam,
Marek
>
> Na 100% wynik explaina był inny przed i po indeksach.
> Usuń indeks, jeszcze raz zrób explain (ale z klauzulą analyze) i pokaż
> plan.
nie robiłem Niestety nie mogę się bawić z tamtą bazą - to żywy organizm.
Moim zadaniem było naprawić problem i to się udało. Spróbuję w wolnej
chwili potrenować na jakiejś bazie na boku.
--
Pozdrawiam,
Marek
Roman Tyczka
Apr 6, 2018, 2:31:44 AM4/6/18
to
On Thu, 5 Apr 2018 22:41:22 +0200, Marek S wrote:
>> Skończyło się to?
>> Nie sądzę.
>
> Nooo... tak jak napisałem. Po założeniu indeksów czas realizacji spadł
> do 0.5s czyli rewelacyjnie. Dlaczego nie sądzisz, że dodanie brakujących
> indeksów na kluczach obcych nie mogło pomóc?
To troll, omijaj.
>> Skończyło się to?
>> Nie sądzę.
>
> Nooo... tak jak napisałem. Po założeniu indeksów czas realizacji spadł
> do 0.5s czyli rewelacyjnie. Dlaczego nie sądzisz, że dodanie brakujących
> indeksów na kluczach obcych nie mogło pomóc?
--
pozdrawiam
Roman Tyczka
Cezary Grądys
Apr 6, 2018, 1:36:41 PM4/6/18
to
W dniu 04.04.2018 o 20:53, Marek S pisze:
Poszukaj w PDF Tuning PostgreSQL Andrzeja Klusiewicza, moze cos tam
znajdziesz.
--
Cezary Grądys <czar...@wa.onet.pl>
znajdziesz.
--
Cezary Grądys <czar...@wa.onet.pl>
Marek S
Apr 6, 2018, 3:59:54 PM4/6/18
to
W dniu 2018-04-06 o 19:36, Cezary Grądys pisze:
>
> Poszukaj w PDF Tuning PostgreSQL Andrzeja Klusiewicza, moze cos tam
> znajdziesz.
Znalazłem bloga. Rewelacja :-) Dzięki.
--
Pozdrawiam,
Marek
>
> Poszukaj w PDF Tuning PostgreSQL Andrzeja Klusiewicza, moze cos tam
> znajdziesz.
--
Pozdrawiam,
Marek
artiun
Apr 8, 2018, 12:53:26 PM4/8/18
to
W dniu 2018-04-06 o 08:31, Roman Tyczka pisze:
Dziękuję, sąsiadowi.. spotkać taką skąpą i upierdliwą osobę to skarb.
PS. weź te swoje uwagi (mam nadzieję, że są małe) wsadź sobie...
Jeśli jestem w studni, to omiń mnie z daleka.
Jakoś nie miałem okazji Cię spotkać.
I Tobie tego życzę.
............ i jakieś głupie odzywki będą .............
--
Artur
PS. weź te swoje uwagi (mam nadzieję, że są małe) wsadź sobie...
Jeśli jestem w studni, to omiń mnie z daleka.
Jakoś nie miałem okazji Cię spotkać.
I Tobie tego życzę.
............ i jakieś głupie odzywki będą .............
--
Artur
artiun
Apr 8, 2018, 1:01:45 PM4/8/18
to
W dniu 2018-04-05 o 12:37, Roman Tyczka pisze:
To nie są dbf'y (tu powinno być - reindeksacja)
jeszcze raz zrób explain (ale z klauzulą analyze) i pokaż
> plan.
>
--
Artur
artiun
Apr 8, 2018, 1:08:23 PM4/8/18
to
W dniu 2018-04-06 o 08:31, Roman Tyczka pisze:
--
Artur
Roman Tyczka
Apr 9, 2018, 2:57:08 AM4/9/18
to
On Sun, 8 Apr 2018 19:00:42 +0200, artiun wrote:
>>> Miałem właśnie przypadek dość złożonego zapytania SQL. Select pracował
>>> ze 20 minut. Próbowałem zapuścić Explain na tym zapytaniu w PGadminie.
>>> Powstały jakieś blokowe schemaciki zawierające dane jak koszt itp.
>>> Szczerze mówiąc - nie mam bladego pojęcia jak z tego wyciągnąć
>>> jakiekolwiek wnioski i ustalić przyczynę, dla której zapytanie tyle
>>> czasu wykonywało się. Faktem jest, że rekordów było kilkaset tysięcy,
>>> parę Joinów i innych konstrukcji multiplikujących tę ilość.
>>>
>>> Poddałem się z Explainem. Podzieliłem zapytanie na mniejsze fragmenty by
>>> odszukać winowajcę. Tak namierzyłem tabelę, w której ktoś... nie założył
>>> indeksów na klucze obce... Czas realizacji po ich założeniu: 0.5s.
>>>
>>> Patrzę na Explaina dla wersji z indeksami i szczerze mówiąc nie widzę
>>> jakiś różnic a w czasie wykonywania jest ogromna.
>>>
>>> Czytałem instrukcję do bazy na w/w temat. Opis jest taki jakby sami
>>> twórcy nie bardzo wiedzieli co z tym zrobić praktycznego.
>>>
>>> A może nie tak diagnostyka powinna wyglądać?
>>
>> Na 100% wynik explaina był inny przed i po indeksach.
>> Usuń indeks,
>
> Tu Ci utnę, usunąć indeks?
> To nie są dbf'y (tu powinno być - reindeksacja)
pieprzysz jak zwykle
>>> Miałem właśnie przypadek dość złożonego zapytania SQL. Select pracował
>>> ze 20 minut. Próbowałem zapuścić Explain na tym zapytaniu w PGadminie.
>>> Powstały jakieś blokowe schemaciki zawierające dane jak koszt itp.
>>> Szczerze mówiąc - nie mam bladego pojęcia jak z tego wyciągnąć
>>> jakiekolwiek wnioski i ustalić przyczynę, dla której zapytanie tyle
>>> czasu wykonywało się. Faktem jest, że rekordów było kilkaset tysięcy,
>>> parę Joinów i innych konstrukcji multiplikujących tę ilość.
>>>
>>> Poddałem się z Explainem. Podzieliłem zapytanie na mniejsze fragmenty by
>>> odszukać winowajcę. Tak namierzyłem tabelę, w której ktoś... nie założył
>>> indeksów na klucze obce... Czas realizacji po ich założeniu: 0.5s.
>>>
>>> Patrzę na Explaina dla wersji z indeksami i szczerze mówiąc nie widzę
>>> jakiś różnic a w czasie wykonywania jest ogromna.
>>>
>>> Czytałem instrukcję do bazy na w/w temat. Opis jest taki jakby sami
>>> twórcy nie bardzo wiedzieli co z tym zrobić praktycznego.
>>>
>>> A może nie tak diagnostyka powinna wyglądać?
>>
>> Na 100% wynik explaina był inny przed i po indeksach.
>> Usuń indeks,
>
> Tu Ci utnę, usunąć indeks?
> To nie są dbf'y (tu powinno być - reindeksacja)
--
pozdrawiam
Roman Tyczka
0 new messages