HypoPG 1.4.5 naprawia crash przy hipotetycznych indeksach — co to zmienia w testowaniu wydajności PostgreSQL

HypoPG 1.4.5 to wydanie rozszerzenia PostgreSQL, które pozwala testować hipotetyczne indeksy bez ich fizycznego tworzenia. Autor projektu, Julien Rouhaud, ogłosił je 2 listopada 2026 r. na liście ogłoszeń PostgreSQL. Zmiana dotyczy wyłącznie poprawek błędów: usunięto „długoletni błąd myślowy” w funkcji hypo_estimate_index oraz błąd w obsłudze relid w hipotetycznych indeksach, który mógł prowadzić do crasha. Rozszerzenie deklaruje zgodność z PostgreSQL 9.2 i nowszymi wersjami.

To istotne dla zespołów, które oceniają wydajność zapytań na kopii bazy lub środowisku stagingowym, zanim wdrożą indeks na produkcji. Crash wywołany obsługą relid jest problemem stabilności narzędzia diagnostycznego, a nie samego PostgreSQL — ale jeśli zdarzy się w trakcie analizy, może zablokować pracę i zafałszować wnioski. Poprawka w hypo_estimate_index dotyczy funkcji szacującej rozmiar hipotetycznego indeksu, więc wpływa na jakość danych wejściowych do decyzji o wdrożeniu.

Co dokładnie zmienia wersja 1.4.5

Wpis źródłowy zawiera changelog z dwiema pozycjami w kategorii „Bug fixes”. Obie są przypisane Julienowi Rouhaudowi. Nie podano numerów zgłoszeń, wersji, w których błędy wprowadzono, ani dokładnych scenariuszy wywołania. Nie ma też informacji o tym, czy poprawki wymagają migracji danych ani czy zmieniają zachowanie funkcji w sposób widoczny dla użytkownika.

Poprawka	Co mówi źródło	Czego źródło nie precyzuje
Błąd w hypo_estimate_index	„Fix long standing thinko” — długoletni błąd myślowy w funkcji szacującej	Jakie wartości były błędne, o ile, w jakich warunkach
Obsługa relid w hipotetycznych indeksach	Błąd „could lead to a crash” — mógł prowadzić do crasha	Jakie zapytanie lub operacja wywoływała crash, czy dotyczyło to konkretnych wersji PostgreSQL

Deklaracja autora jest jednoznaczna co do charakteru wydania: to wydanie poprawkowe. Nie ma w nim nowych funkcji ani zmian w interfejsie rozszerzenia. Wszystkie wnioski o szerszym wpływie na planowanie zapytań są interpretacją, nie faktem z materiału źródłowego.

Tło techniczne: czym są hipotetyczne indeksy

Planista zapytań PostgreSQL podejmuje decyzje na podstawie statystyk i informacji o dostępnych indeksach. Jeśli indeks nie istnieje, planista go nie rozważy — nawet jeśli w praktyce bardzo by pomógł. Klasyczna metoda sprawdzenia to utworzenie indeksu na kopii bazy i porównanie planów oraz czasów wykonania. To działa, ale wymaga miejsca na dysku, czasu budowy indeksu i obciąża środowisko testowe.

Hipotetyczny indeks to wpis w katalogu, który planista widzi, ale który nie ma fizycznej struktury danych. Nie da się go użyć do odczytu wierszy — służy wyłącznie do tego, żeby planista ocenił, czy w ogóle rozważyłby taki indeks i jaki plan by zbudował. HypoPG dostarcza funkcje do tworzenia, usuwania i wyliczania takich indeksów oraz do sprawdzania, czy planista je uwzględnia.

Jak to wygląda w praktyce

Typowy przebieg pracy jest prosty: tworzymy hipotetyczny indeks na kolumnie lub zestawie kolumn, uruchamiamy zapytanie z EXPLAIN i sprawdzamy, czy w planie pojawia się skan po hipotetycznym indeksie. Następnie porównujemy szacowany koszt z planem bez indeksu. Jeśli różnica jest duża, mamy sygnał, że warto rozważyć realne wdrożenie. Jeśli planista nadal wybiera skan sekwencyjny, hipotetyczny indeks prawdopodobnie nie rozwiąże problemu.

Warto podkreślić ograniczenie: hipotetyczny indeks nie zawiera danych. Planista korzysta z oszacowań, nie z rzeczywistych odczytów. To oznacza, że test odpowiada na pytanie „czy planista w ogóle rozważy taki indeks i jaki plan zbuduje”, a nie „jak szybko zapytanie wykona się z tym indeksem”. Rzeczywisty czas wykonania zależy od rozkładu danych, rozmiaru tabeli, stanu cache i konfiguracji serwera.

Realne konsekwencje obu błędów

Błąd w hypo_estimate_index dotyczy funkcji szacującej rozmiar indeksu. Jeśli szacunek był błędny, zespół mógł podejmować decyzje na podstawie zawyżonych lub zaniżonych wartości. Skutki są pośrednie: zły szacunek rozmiaru przekłada się na błędną ocenę kosztu utrzymania indeksu, miejsca na dysku i czasu budowy. Źródło nie podaje kierunku ani skali błędu, więc nie można twierdzić, że indeksy były systematycznie zawyżane lub zaniżane.

Błąd obsługi relid jest poważniejszy z perspektywy pracy operacyjnej. Crash narzędzia w trakcie analizy oznacza przerwany test, konieczność restartu sesji i ryzyko utraty kontekstu. Jeśli zdarzy się na środowisku stagingowym, które dzieli zasoby z innymi testami, może zaburzyć wyniki. Źródło nie mówi, czy crash dotyczył całego serwera PostgreSQL, czy tylko sesji — to rozróżnienie ma znaczenie dla oceny ryzyka, ale materiał go nie rozstrzyga.

Materiał źródłowy potwierdza istnienie dwóch błędów i ich naprawę. Nie potwierdza, jakie dokładnie zapytania je wywoływały ani czy dotyczyły wszystkich wspieranych wersji PostgreSQL.

Scenariusze ryzyka

Poniższe scenariusze to interpretacja możliwych konsekwencji, nie fakty ze źródła. Opierają się na charakterze błędów opisanych w changelogu.

• Przerwana analiza wydajności. Crash w trakcie serii testów EXPLAIN przerywa pracę i wymaga powtórzenia. W zespole z jednym środowiskiem stagingowym opóźnia to decyzję o wdrożeniu indeksu.
• Błędne wnioski o rozmiarze. Nieprawidłowy szacunek w hypo_estimate_index może prowadzić do odrzucenia dobrego indeksu lub zaakceptowania takiego, który w praktyce zajmie więcej miejsca, niż zakładano.
• Fałszywe poczucie bezpieczeństwa. Jeśli zespół testuje tylko na hipotetycznych indeksach i nie weryfikuje wyniku na realnym wdrożeniu, błąd szacowania może pozostać niewykryty aż do produkcji.
• Problemy z automatyzacją. Skrypty, które parsują wyniki funkcji HypoPG, mogą działać na błędnych danych wejściowych. To ryzyko dotyczy zespołów, które wbudowały HypoPG w pipeline testowy.

Jak sprawdzić, czy problem dotyczy Twojego środowiska

Krótka weryfikacja nie wymaga dostępu do produkcji. Wystarczy środowisko testowe z zainstalowanym rozszerzeniem.

1. Sprawdź zainstalowaną wersję rozszerzenia. W psql wykonaj dx hypopg lub zapytaj katalog rozszerzeń o wersję.
2. Porównaj wersję z 1.4.5. Jeśli masz starszą, jesteś w grupie objętej poprawkami.
3. Sprawdź, czy w Twoich testach używana jest funkcja hypo_estimate_index. Jeśli tak, jej wyniki sprzed aktualizacji mogą być obarczone błędem.
4. Przejrzyj logi PostgreSQL pod kątem nieoczekiwanych restartów sesji lub błędów w trakcie sesji z HypoPG.
5. Ustal, czy środowisko testowe jest współdzielone. Jeśli tak, zaplanuj aktualizację poza godzinami pracy innych zespołów.

Plan reakcji krok po kroku

1. Zabezpiecz kontekst. Zapisz wyniki wcześniejszych testów i wersję rozszerzenia, na której je wykonano. Bez tego nie odróżnisz wyników sprzed i po aktualizacji.
2. Zaplanuj okno aktualizacji. To wydanie poprawkowe, ale każda zmiana w rozszerzeniu wymaga restartu sesji lub serwera, zależnie od sposobu instalacji. Sprawdź procedurę dla swojego środowiska.
3. Zainstaluj 1.4.5. Źródło wskazuje repozytorium GitHub jako miejsce pobierania wydań. Postępuj zgodnie z dokumentacją projektu dla swojej wersji PostgreSQL.
4. Powtórz kluczowe testy. Uruchom te same zapytania i te same hipotetyczne indeksy, które testowałeś wcześniej. Porównaj plany i szacunki rozmiaru.
5. Zapisz różnice. Jeśli szacunki rozmiaru zmieniły się istotnie, zaktualizuj wnioski i dokumentację decyzji o indeksach.
6. Zweryfikuj na realnym wdrożeniu. Dla indeksów, które przeszły test hipotetyczny, zaplanuj kontrolowane wdrożenie na kopii lub stagingu z rzeczywistymi danymi.

Typowe błędy przy testowaniu hipotetycznych indeksów

• Traktowanie szacunku jak pomiaru. Funkcja szacująca rozmiar nie mierzy rzeczywistego zużycia miejsca. To przybliżenie oparte na statystykach.
• Pomijanie EXPLAIN ANALYZE. Sam plan bez wykonania nie pokazuje rzeczywistego czasu. Hipotetyczny indeks pomaga w ocenie planu, nie w pomiarze wydajności.
• Testowanie na niereprezentatywnych danych. Jeśli kopia ma inny rozkład danych niż produkcja, planista może podjąć inną decyzję niż w rzeczywistości.
• Brak porównania z planem bazowym. Test bez punktu odniesienia nie mówi, czy hipotetyczny indeks cokolwiek zmienia.
• Mylenie hipotetycznego indeksu z realnym. Hipotetyczny indeks nie przyspiesza zapytań. Służy tylko do analizy planu.

Działania krótkoterminowe

Najpilniejsze to aktualizacja do 1.4.5 na środowiskach, gdzie HypoPG jest używany do analiz. Jeśli nie możesz zaktualizować od razu, ogranicz ekspozycję: unikaj uruchamiania testów z hipotetycznymi indeksami w sesjach współdzielonych z innymi zadaniami krytycznymi i zapisuj wyniki przed każdą serią, żeby crash nie zniszczył kontekstu.

Drugi krok to przegląd wyników sprzed aktualizacji. Jeśli podejmowałeś decyzje o indeksach na podstawie hypo_estimate_index, oznacz te decyzje jako wymagające ponownej weryfikacji. Nie musisz ich od razu zmieniać — wystarczy, że wiesz, które wnioski opierały się na danych z wersji objętej poprawką.

Działania długoterminowe

Warto wpisać HypoPG w powtarzalny proces oceny wydajności, a nie traktować go jako jednorazowe narzędzie. Proces powinien mieć stałe etapy: zebranie zapytań do analizy, test hipotetyczny, weryfikacja na kopii z realnymi danymi, kontrolowane wdrożenie i pomiar po wdrożeniu. Każdy etap powinien zostawiać zapis wersji narzędzia i konfiguracji, żeby wyniki były porównywalne w czasie.

Drugi element to polityka aktualizacji rozszerzeń. Wydania poprawkowe takie jak 1.4.5 powinny trafiać na środowiska testowe w ustalonym rytmie, a nie dopiero przy okazji większych zmian. To szczególnie ważne przy narzędziach diagnostycznych, których wyniki wpływają na decyzje infrastrukturalne.

Checklista przed i po aktualizacji

Etap	Punkty do sprawdzenia
Przed	Wersja rozszerzenia, lista testów zależnych od hypo_estimate_index, zapisane wyniki sprzed zmian, okno serwisowe
Instalacja	Zgodność z wersją PostgreSQL, sposób instalacji, restart wymagany przez środowisko
Po	Powtórzenie testów, porównanie szacunków, aktualizacja dokumentacji decyzji, weryfikacja na kopii z realnymi danymi

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy nie musi znać szczegółów technicznych, ale powinien wiedzieć, że narzędzia diagnostyczne też mają błędy i wymagają aktualizacji. Jeśli zespół podejmuje decyzje o indeksach na podstawie testów hipotetycznych, warto zapytać, czy wyniki sprzed ostatniej aktualizacji zostały zweryfikowane. To pytanie o jakość decyzji infrastrukturalnych, nie o szczegóły implementacji.

Administrator powinien wykonać cztery czynności: sprawdzić wersję HypoPG na wszystkich środowiskach, zaplanować aktualizację do 1.4.5, powtórzyć testy zależne od hypo_estimate_index i przejrzeć logi pod kątem wcześniejszych crashów. Dodatkowo warto ustalić, kto odpowiada za aktualizacje rozszerzeń i w jakim rytmie są one wdrażane. Przy środowiskach współdzielonych aktualizację należy skoordynować z zespołami, które korzystają z tych samych testów.

Ograniczenia materiału i czego nie wiadomo

Źródło jest krótkim wpisem ogłoszeniowym. Nie zawiera numerów zgłoszeń, opisów przyczynowych ani informacji o tym, które wersje HypoPG były dotknięte błędami. Nie wiadomo, czy crash dotyczył wszystkich wspieranych wersji PostgreSQL, czy tylko niektórych. Nie ma też danych o tym, jak często problem występował w praktyce.

Z tego powodu nie należy wyciągać wniosków o skali problemu w populacji użytkowników. Można natomiast stwierdzić, że wydanie poprawkowe jest dostępne, a jego zastosowanie usuwa opisane błędy. To wystarczający powód, żeby zaplanować aktualizację na środowiskach, gdzie HypoPG jest używany do analiz wydajności.

Ostatnia uwaga praktyczna: hipotetyczne indeksy są narzędziem wspomagającym decyzje, a nie zamiennikiem testów na realnych danych. Nawet po aktualizacji do 1.4.5 wynik testu hipotetycznego należy traktować jako sygnał do dalszej weryfikacji, nie jako ostateczny dowód, że indeks poprawi wydajność produkcji.

Praktyczna weryfikacja po aktualizacji do HypoPG 1.4.5

Weryfikacja po aktualizacji nie polega na jednorazowym uruchomieniu testu. Powinna być powtarzalna i udokumentowana, tak aby każdy członek zespołu mógł odtworzyć wynik. Poniższe sekcje opisują konkretne kroki, które można wykonać w środowisku testowym z zainstalowanym HypoPG, bez dostępu do produkcji.

Odtworzenie scenariusza testowego

Pierwszym krokiem jest odtworzenie dokładnie tego samego scenariusza, który był używany przed aktualizacją. Chodzi o te same zapytania, te same hipotetyczne indeksy i te same dane wejściowe. Bez tego porównanie wyników sprzed i po aktualizacji nie ma podstawy.

• Zapisz listę zapytań objętych testem, wraz z ich pełną treścią.
• Zapisz definicje hipotetycznych indeksów użytych w testach.
• Zapisz wersję rozszerzenia, na której wykonano testy przed aktualizacją.
• Zapisz wersję PostgreSQL używaną w środowisku testowym.
• Zapisz konfigurację istotną dla planisty, jeśli była zmieniana między testami.

Dopiero mając komplet tych danych, można powtórzyć serię testów po instalacji 1.4.5 i porównać wyniki w sposób, który ma sens. Źródło wskazuje, że poprawki dotyczą funkcji hypo_estimate_index oraz obsługi relid w hipotetycznych indeksach, więc właśnie te elementy powinny znaleźć się w scenariuszu weryfikacyjnym.

Porównanie szacunków rozmiaru

Funkcja hypo_estimate_index zwraca przybliżenie, nie pomiar. Po aktualizacji warto zestawić szacunki sprzed i po zmianie dla tych samych indeksów. Różnica nie musi oznaczać błędu — może odzwierciedlać poprawioną logikę szacowania. Ważne, aby różnicę zauważyć i zapisać, a nie pominąć.

1. Uruchom hypo_estimate_index dla każdego indeksu z listy testowej.
2. Zapisz wynik obok wartości uzyskanej przed aktualizacją.
3. Oznacz indeksy, dla których różnica jest istotna z punktu widzenia decyzji o wdrożeniu.
4. Dla oznaczonych indeksów zaplanuj weryfikację na kopii z realnymi danymi.

Istotność różnicy zależy od kontekstu: przy małych tabelach niewielka zmiana szacunku może nie mieć znaczenia, przy dużych może przesądzić o odrzuceniu lub akceptacji indeksu. Kryterium istotności powinien ustalić zespół przed uruchomieniem porównania, aby nie dopasowywać progu do wyniku.

Weryfikacja obsługi relid

Changelog wymienia poprawkę obsługi relid w hipotetycznych indeksach, która mogła prowadzić do crashu. Po aktualizacji warto wykonać test, który wcześniej powodował problem lub był do niego zbliżony: serie operacji na hipotetycznych indeksach w ramach jednej sesji, z odwołaniami do różnych relacji.

• Uruchom serię testów w jednej sesji, bez przerywania między krokami.
• Sprawdź, czy sesja kończy się poprawnie i czy wyniki są kompletne.
• Przejrzyj logi PostgreSQL pod kątem błędów i nieoczekiwanych restartów sesji.
• Powtórz test w sesji współdzielonej, jeśli takie środowisko jest używane.

Celem nie jest udowodnienie, że problem nie występuje w każdej możliwej konfiguracji, lecz potwierdzenie, że w Twoim scenariuszu testowym objawy opisane w changelogu nie występują po aktualizacji. To praktyczna weryfikacja, nie gwarancja dla całej populacji użytkowników.

Monitoring po wdrożeniu

Monitoring po wdrożeniu powinien być prosty i możliwy do utrzymania. Nie chodzi o rozbudowany system metryk, lecz o kilka punktów kontrolnych, które pozwolą zauważyć, że coś odbiega od oczekiwań. Zakres monitoringu zależy od tego, jak HypoPG jest używany: czy tylko ręcznie w sesjach analitycznych, czy także w pipeline testowym.

Co obserwować w logach

Logi PostgreSQL są pierwszym miejscem, w którym widać nieoczekiwane zachowanie. Po aktualizacji warto ustalić krótki okres obserwacji i przejrzeć logi pod kątem sygnałów, które wcześniej mogły być pomijane.

• Nieoczekiwane restarty sesji w trakcie pracy z hipotetycznymi indeksami.
• Błędy zgłaszane w sesjach, w których używane są funkcje HypoPG.
• Komunikaty związane z obsługą relacji w kontekście hipotetycznych indeksów.
• Powtarzające się błędy w tych samych zapytaniach lub scenariuszach.

Okres obserwacji powinien być ustalony z góry, podobnie jak osoba odpowiedzialna za przegląd. Bez tego monitoring staje się jednorazowym sprawdzeniem, które łatwo pominąć przy innych zadaniach.

Monitoring w pipeline testowym

Jeśli HypoPG jest wbudowany w pipeline, monitoring powinien objąć także wyniki generowane automatycznie. Skrypty parsujące wyniki funkcji HypoPG mogły wcześniej działać na danych obarczonych błędem szacowania. Po aktualizacji warto sprawdzić, czy ich wyniki są nadal sensowne.

1. Uruchom pipeline na znanym zestawie testowym i zapisz wyniki.
2. Porównaj wyniki z tymi sprzed aktualizacji.
3. Sprawdź, czy skrypty nie zgłaszają błędów parsowania.
4. Ustal, kto przegląda wyniki i jak często.

Warto też zapisywać wersję rozszerzenia razem z wynikami pipeline’u. Dzięki temu przy kolejnej aktualizacji będzie wiadomo, które wyniki pochodzą z której wersji, a porównania pozostaną możliwe.

Punkty kontrolne po wdrożeniu

Monitoring nie musi być ciągły. Wystarczy kilka punktów kontrolnych w ustalonych odstępach czasu, aby wychwycić problemy, które nie ujawniły się od razu. Poniższa lista porządkuje to podejście.

• Pierwszy przegląd logów bezpośrednio po aktualizacji.
• Drugi przegląd po zakończeniu pierwszej pełnej serii testów.
• Trzeci przegląd po wdrożeniu pierwszego indeksu zweryfikowanego hipotetycznie.
• Przegląd wyników pipeline’u przy każdym jego uruchomieniu w ustalonym okresie.

Każdy przegląd powinien kończyć się krótkim zapisem: data, zakres sprawdzenia, wynik, osoba odpowiedzialna. Taki zapis jest prosty, a jednocześnie pozwala odtworzyć historię, gdy pojawi się pytanie o jakość decyzji infrastrukturalnych.

Checklisty operacyjne

Checklisty porządkują czynności, które łatwo pominąć przy aktualizacji narzędzia diagnostycznego. Poniższe listy są niezależne od istniejącej tabeli i obejmują weryfikację, instalację oraz monitoring po wdrożeniu.

Checklista weryfikacji przed aktualizacją

• Czy znana jest wersja HypoPG na każdym środowisku, na którym rozszerzenie jest zainstalowane?
• Czy sporządzono listę testów zależnych od hypo_estimate_index?
• Czy zapisano wyniki tych testów wraz z wersją rozszerzenia, na której je wykonano?
• Czy ustalono, które środowiska są współdzielone z innymi zespołami?
• Czy zaplanowano okno aktualizacji poza godzinami pracy innych zespołów?
• Czy sprawdzono procedurę instalacji dla używanej wersji PostgreSQL?

Checklista instalacji

• Czy pakiet lub źródło instalacji pochodzi z repozytorium wskazanego w ogłoszeniu wydania?
• Czy sposób instalacji jest zgodny z dokumentacją projektu dla danej wersji PostgreSQL?
• Czy wiadomo, czy środowisko wymaga restartu sesji, czy serwera?
• Czy po instalacji potwierdzono wersję rozszerzenia w katalogu rozszerzeń?
• Czy zapisano datę i osobę wykonującą aktualizację?

Checklista weryfikacji po aktualizacji

1. Powtórz testy z listy zależnej od hypo_estimate_index.
2. Porównaj szacunki rozmiaru sprzed i po aktualizacji.
3. Oznacz decyzje o indeksach wymagające ponownej weryfikacji.
4. Uruchom scenariusz testowy obejmujący obsługę relid w hipotetycznych indeksach.
5. Przejrzyj logi pod kątem błędów i nieoczekiwanych restartów sesji.
6. Zaktualizuj dokumentację decyzji o indeksach na podstawie nowych wyników.
7. Zaplanuj weryfikację na kopii z realnymi danymi dla indeksów oznaczonych jako istotne.

Checklista monitoringu po wdrożeniu

• Czy ustalono okres obserwacji logów i osobę odpowiedzialną za przegląd?
• Czy sprawdzono wyniki pipeline’u pod kątem błędów parsowania?
• Czy zapisano wersję rozszerzenia razem z wynikami pipeline’u?
• Czy wykonano zaplanowane punkty kontrolne po wdrożeniu?
• Czy każdy przegląd został udokumentowany datą, zakresem i wynikiem?
• Czy ustalono rytm kolejnych aktualizacji rozszerzeń diagnostycznych?

Jak wykorzystać checklisty w praktyce

Checklista nie zastępuje decyzji, ale zmniejsza ryzyko pominięcia kroku, który w danym momencie wydaje się oczywisty. Największą wartość ma wtedy, gdy jest używana konsekwentnie przy każdej aktualizacji, a nie tylko przy wydaniach uznanych za ryzykowne.

Warto przypisać poszczególne punkty do konkretnych osób lub ról. Przy środowiskach współdzielonych część czynności wymaga koordynacji z innymi zespołami, więc przypisanie odpowiedzialności ułatwia planowanie okna aktualizacji. Checklista powinna też zawierać miejsce na zapis wyniku każdego punktu, aby po zakończeniu prac pozostał ślad pozwalający odtworzyć przebieg aktualizacji.

Ostatni element to przegląd samych checklist po zakończeniu wdrożenia. Jeśli któryś punkt okazał się zbędny lub brakowało w nim istotnej czynności, warto go poprawić przed kolejną aktualizacją. Dzięki temu checklisty pozostają narzędziem praktycznym, a nie formalnością wypełnianą dla porządku.

Ograniczenia weryfikacji i monitoringu

Zakres weryfikacji i monitoringu zależy od tego, co można sprawdzić w danym środowisku. Źródło nie podaje, które wersje HypoPG były dotknięte błędami ani jak często problem występował w praktyce. Nie wiadomo też, czy crash dotyczył wszystkich wspieranych wersji PostgreSQL, czy tylko niektórych.

Z tego powodu wyniki weryfikacji należy traktować jako potwierdzenie dla konkretnego scenariusza testowego, a nie jako dowód braku problemu w każdej konfiguracji. Podobnie monitoring po wdrożeniu pokazuje, czy w obserwowanym okresie nie pojawiły się sygnały problemu — nie daje gwarancji na przyszłość. Te ograniczenia warto zapisać razem z wynikami, aby przy późniejszym przeglądzie decyzji było jasne, na jakiej podstawie zostały podjęte.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. HypoPG 1.4.5 is out! (www.postgresql.org)

Zdjęcie wyróżniające: panumas nikhomkhai / Pexels.