W dokumentacji PostgreSQL dla Ograniczeń jest napisane
Ograniczenie niepuste jest funkcjonalnie równoważne z utworzeniem ograniczenia sprawdzającego
CHECK (column_name IS NOT NULL)
, ale w PostgreSQL tworzenie wyraźnego ograniczenia niepustego jest bardziej wydajne.
zastanawiam się
- Co dokładnie oznacza „bardziej wydajny”?
- Jakie są niekorzystne skutki używania
CHECK (column_name IS NOT NULL)
zamiastSET NOT NULL
?
Chcę mieć możliwość dodania NOT VALID
CHECK
ograniczenia i zweryfikowania go osobno (więc AccessExclusiveLock
wstrzymanie trwa tylko przez krótki czas w celu dodania ograniczenia, a następnie ShareUpdateExclusiveLock
wstrzymanie dla dłuższego kroku sprawdzania poprawności):
ALTER TABLE table_name
ADD CONSTRAINT column_constraint
CHECK (column_name IS NOT NULL)
NOT VALID;
ALTER TABLE table_name
VALIDATE CONSTRAINT column_constraint;
Zamiast:
ALTER TABLE table_name
ALTER COLUMN column_name
SET NOT NULL;
postgresql
postgresql-9.5
check-constraints
Robin Joseph
źródło
źródło
not in
przypadku obu wariantów? Czy są takie same czy różnią się?Odpowiedzi:
Moje dzikie przypuszczenie: „bardziej wydajny” oznacza „mniej czasu potrzeba na sprawdzenie” (przewaga czasowa). Może to również oznaczać „potrzeba mniej pamięci do wykonania testu” (przewaga miejsca). Może to również oznaczać „ma mniej skutków ubocznych” (takich jak nie blokowanie czegoś lub blokowanie go na krótsze okresy czasu) ... ale nie mam sposobu, aby poznać lub sprawdzić tę „dodatkową zaletę”.
Nie mogę wymyślić łatwego sposobu na sprawdzenie możliwej przewagi przestrzeni (co, jak sądzę, nie jest tak ważne, gdy pamięć jest obecnie tania). Z drugiej strony nie jest tak trudno sprawdzić możliwą przewagę czasową: po prostu utwórz dwie tabele, które są takie same, z jedynym wyjątkiem ograniczenia. Wstaw wystarczająco dużą liczbę wierszy, powtórz kilka razy i sprawdź czasy.
Oto konfiguracja tabeli:
To jest dodatkowy stolik, służący do przechowywania czasów:
I to jest test przeprowadzony przy użyciu pgAdmin III i funkcji pgScript .
Wynik podsumowano w następującym zapytaniu:
Z następującymi wynikami:
Wykres wartości pokazuje ważną zmienność:
W praktyce więc SPRAWDŹ (kolumna NIE JEST NULLOWANA) jest bardzo nieznacznie wolniejsza (o 0,5%). Jednak ta niewielka różnica może wynikać z dowolnego losowego powodu, pod warunkiem, że zmienność czasów jest znacznie większa. Nie jest to więc statystycznie istotne.
Z praktycznego punktu widzenia bardzo zignorowałbym „bardziej wydajne”
NOT NULL
, ponieważ tak naprawdę nie widzę, żeby miało to znaczenie; mając na uwadze, że uważam, że brak aneksuAccessExclusiveLock
jest zaletą.źródło