Nasz serwer PostgreSQL 9.2.4 bierze 0.69s przeciętnie (15000 sprawozdań), aby wykonaćDlaczego SET CONSTRAINTS ALL DEFERRED na Postgresql zajmuje dużo czasu?
SET CONSTRAINTS ALL DEFERRED
Dlaczego powinno to być?
Używając INITIALLY DEFERRED w definicji tabeli i nie używając SET CONSTRAINTS .. wyeliminujesz ten czas lub po prostu ukryjesz w innym miejscu?
Imho, to prawdopodobnie dlatego, że za każdym razem, gdy uruchamiasz to stwierdzenie, to, co dzieje się w tle, jest duża aktualizacja definicji tabel znajdujących się w pg_catalog. Innymi słowy, dodajesz martwe wiersze do pg_catalog, co powoduje, że coraz większe ilości miejsca na dysku są odwiedzane podczas odpowiednich seq scans.
Jeśli naprawdę używasz oświadczenia 15k razy dziennie, być może musisz nadać swojemu schematowi lub obiegowi pracy zimny, twardy wygląd?
Aha. Czy to oznacza, że za pomocą "INITIALLY DEFERRED" w definicjach tabel można to rozwiązać? Baza danych zawiera ponad 5000 tabel w około 100 schematach. Założyłem, że "USTAWIENIA ZASIĘGU WSZYSTKIEGO ODRODZONEGO" ustawiają tylko flagę na tx i będą szybkie. –
Technicznie nie jesteś niepoprawny. W rzeczywistości ustawia flagę na ograniczenie za każdym razem, gdy edytujesz tabele (z powrotem * i * dalej). Kłopot w tym, że masz flagę na ograniczenie, które się zmienia. To dużo aktualizacji (tzn. Usuwanie + wstawianie) instrukcji; innymi słowy dostęp do dysku. I tak, idź z odroczonymi początkowo odroczonymi ograniczeniami tam, gdzie to właściwe, jeśli to rozwiąże twój problem. –
To jest nieprawidłowe. SET CONSTRAINTS nie dotyka katalogów systemowych. –
Przejrzałem kod źródłowy. Zasadniczo, SET CONSTRAINTS ALL DEFERRED nie robi nic poza ustawieniem globalnej zmiennej zwracając uwagę, że "wszystkie odpowiednie ograniczenia są teraz odroczone". Jedyną nietuzinkową pracą, którą wykonano, jest gra w subtransakcjach. Jeśli dotyczy to Twojego przypadku, spróbuj bez. (Zauważ, że subtransakcje zawierają bloki wyjątków PL/pgSQL.)
Hmm. Cóż, jak dla nas "SET CONSTRAINTS ALL DEFERRED" "przyjął średnio 0,69 s za transakcję. O ile mi wiadomo, nie używamy subtransakcji (tj. Nie celowo). Używamy sterownika JDBC Postgres, więc może to coś robi. Otrzymujemy również ostrzeżenia "TRANSAKCJA JUŻ W POSTACIE", jeśli to wskazówka. Sprawiliśmy, że ten problem zniknął, wykorzystując na razie "INICJALNIE PRZEWIDZIANE". –
Jak zmierzyłeś ten czas? Czy obejmuje to narzut komunikacji między klientem a serwerem? Dlaczego w ogóle jest to problem? Jak często uruchamiasz to stwierdzenie? –
Czas jest mierzony poprzez analizę plików dziennika za pomocą pgfouine, tj. Jest to czas po stronie serwera zgłoszony przez PostgreSQL. W ciągu dnia wykonuje 15000 razy i trwa łącznie ponad 3 godziny. Ten serwer wstawia/aktualizuje wiele partii wierszy i staramy się zwiększyć przepustowość. –
Dlaczego, na ziemi, wykonujesz to oświadczenie 15000 razy dziennie? –