Zarządzanie bazami danych to niełatwe zadanie i może być frustrujące, nie wiedząc, co dzieje się pod osłonami. Niezależnie od tego, czy próbujesz dowiedzieć się, czy nowe indeksy są pomocne, liczba transakcji w bazie danych jest liczona w określonym czasie, czy też kto jest połączony z bazą danych w danym momencie, dane, które pozwalają administratorom naprawdę wiedzieć, jak działają ich bazy danych, są najważniejsze. Na szczęście, dzięki PostgreSQL, wszystkie te dane są dostępne w katalogu systemowym PostgreSQL.
Katalog systemu PostgreSQL to schemat z tabelami i widokami, które zawierają metadane dotyczące wszystkich innych obiektów w bazie danych i nie tylko. Dzięki niemu możemy odkryć, kiedy mają miejsce różne operacje, w jaki sposób uzyskuje się dostęp do tabel lub indeksów, a nawet czy system bazy danych odczytuje informacje z pamięci lub musi pobrać dane z dysku.
Tutaj omówimy przegląd katalogu systemowego i podkreślimy, jak go czytać i jak wyciągnąć z niego przydatne informacje. Niektóre metadane są proste, a inne wymagają trochę przetrawienia, aby wygenerować naprawdę przydatne informacje. Tak czy inaczej, PostgreSQL daje nam świetną platformę do budowania wszelkich potrzebnych nam informacji o samej bazie danych.
Katalog PostgreSQL
PostgreSQL przechowuje informacje o metadanych o bazie danych i klastrze w schemacie „pg_catalog”. Informacje te są częściowo wykorzystywane przez sam PostgreSQL do śledzenia samych rzeczy, ale są również prezentowane tak, aby osoby/procesy z zewnątrz mogły zrozumieć również wnętrze baz danych.
Katalog PostgreSQL ma dość solidną zasadę:patrz, nie dotykaj. Podczas gdy PostgreSQL przechowuje wszystkie te informacje w tabelach, tak jak zrobiłaby to każda inna aplikacja, dane w tabelach są w pełni zarządzane przez sam PostgreSQL i nie powinny być modyfikowane, chyba że jest to absolutna sytuacja awaryjna, a nawet wtedy prawdopodobna jest odbudowa.
Omówimy kilka przydatnych tabel katalogowych, jak czytać dane i sprytne rzeczy, które możemy zrobić z samymi danymi. W katalogu jest sporo tabel, których nie będziemy omawiać, ale wszystkie informacje dotyczące tych różnych tabel można znaleźć w oficjalnej dokumentacji PostgreSQL.
Metadane dotyczące całego systemu
Duża część tabel, do których możemy wykonać zapytania w katalogu, to tabele „systemowe”, gdzie nie ma znaczenia, z jaką bazą danych jesteśmy połączeni, dane reprezentują cały klaster, a nie pojedynczą bazę danych.
Informacje o bazie danych
Ogólne informacje o bazie danych są przechowywane w pg_database, a statystyki są przechowywane w pg_stat_database.
pg_database:
postgres=# SELECT oid,* FROM pg_database WHERE datname = 'severalnines';
-[ RECORD 1 ]-+-------------
oid | 16396
datname | severalnines
datdba | 10
encoding | 6
datcollate | en_US.UTF-8
datctype | en_US.UTF-8
datistemplate | f
datallowconn | t
datconnlimit | -1
datlastsysoid | 13804
datfrozenxid | 548
datminmxid | 1
dattablespace | 1663
datacl |Tabela pg_database zawiera wiersz dla każdej bazy danych w klastrze, w tym trzech, które wychodzą z pudełka (postgres, template0 i template1). Ten wiersz zawiera informacje dotyczące kodowania, limitu połączeń i innych podstawowych metadanych.
Kolumny zainteresowania:
oid — identyfikator obiektu, który nie pojawia się w danych wyjściowych zapytania, chyba że istnieje bezpośrednie odwołanie. Ten numer będzie zgodny z katalogiem w katalogu danych klastrów
nazwa_danych — nazwa bazy danych.
datdba — właściciel bazy danych, odwołania do oid pg_authid .oid.
encoding — kodowanie znaków dla tej bazy danych, pg_encoding_to_char() zostanie przekonwertowane na czytelną nazwę.
datconnlimit — maksymalna liczba jednoczesnych połączeń dozwolona w bazie danych.
dattablespace — domyślna przestrzeń tabel dla tej bazy danych, odwołuje się do pg_tablespace.oid.
pg_stat_database:
postgres=# SELECT * FROM pg_stat_database WHERE datname = 'severalnines';
-[ RECORD 1 ]--+------------------------------
datid | 13805
datname | postgres
numbackends | 2
xact_commit | 477460
xact_rollback | 13
blks_read | 417
blks_hit | 16488702
tup_returned | 252376522
tup_fetched | 2637123
tup_inserted | 114
tup_updated | 3
tup_deleted | 1
conflicts | 0
temp_files | 0
temp_bytes | 0
deadlocks | 0
blk_read_time | 0
blk_write_time | 0
stats_reset | 2018-02-04 19:52:39.129052+00Ta tabela statystyk to miejsce, w którym otrzymujemy interesujące i przydatne dane. Każdy wiersz w tej tabeli zawiera aktualne dane dla każdej bazy danych i może być okresowo eksportowany w celu śledzenia w czasie, jeśli chcesz monitorować zmiany.
Transakcje
Informacje o transakcjach można znaleźć w kolumnach xact_commit i xact_rollback, które zawierają odpowiednio liczbę transakcji, które baza danych zatwierdziła i wycofała. Pomoże to pokazać, jak aktywna jest baza danych, a także wykryć możliwe awarie programów, które mogą powodować błędy lub cofać się w alarmującym tempie.
Dostęp do dysku i pamięci
Informacje o tym, czy dane są pobierane z dysku lub pamięci, są przechowywane w kolumnach blks_read i blks_hit. Blks_read pokazuje liczbę bloków, które ta baza danych odczytała z dysku, podczas gdy blks_hit pokazuje liczbę bloków znalezionych w buforze PostgreSQL (reprezentowanym przez parametr shared_buffers). Ponieważ pamięć RAM jest znacznie szybsza niż dysk, idealnie byłoby, gdyby blks_hit był stale wyższy niż blks_read, a jeśli nie, możemy ponownie ocenić dostępną pamięć.
Krotki
Kolejne kilka kolumn dotyczy krotek. Tup_returned to liczba wierszy zwrócona w bazie danych, która jest liczbą wierszy odczytanych przez skanowanie sekwencyjne z tabeli lub liczbą wpisów indeksu zwróconych z indeksu”. Tup_fetched to liczba wierszy pobranych z bazy danych, co oznacza, że były one wynikiem skanowania bitmap, czyli liczby wierszy tabeli pobranych przez skanowanie bitmapy z tabeli lub wierszy tabeli pobranych przez proste skanowanie indeksu, jeśli używany jest indeks.
Mamy również tup_inserted, tup_updated i tup_deleted, które reprezentują odpowiednio liczbę wstawionych, zaktualizowanych i usuniętych krotek w tej bazie danych. Pomoże to zrozumieć, w jaki sposób dane wchodzą, zmieniają się i opuszczają bazę danych. Ponieważ zaktualizowane i usunięte krotki skutkują martwymi wierszami, wysokie wartości w tych kolumnach sugerowałyby dostosowanie operacji automatycznego odkurzania do potrzeb aktywności bazy danych.
Konflikty
Jeśli dana baza danych jest serwerem rezerwowym, konflikty kolumn przydają się jako sposób śledzenia, ile zapytań zostało anulowanych z powodu konfliktów z serwerem rezerwowym będącym w „trybie odzyskiwania”. Jeśli nie jest to klaster w trybie gotowości, tę kolumnę można zignorować.
Pliki / dane tymczasowe
Czasami zapytania będą musiały być zapisywane w plikach tymczasowych. Może się to zdarzyć, gdy ilość work_mem przydzielona do połączenia została zużyta i konieczne jest kontynuowanie operacji sortowania na dysku, a nie w pamięci. Kolumna temp_files śledzi liczbę tych plików, które zostały utworzone, a temp_bytes śledzi całkowity rozmiar wszystkich używanych plików tymczasowych. Te dane mogą pomóc w dostrojeniu work_mem, a nawet w znalezieniu zapytań, które mogą wymagać ponownego zapisu, jeśli rozmiar pliku tymczasowego jest zbyt duży.
Zakleszczenia
Kolumna zakleszczeń śledzi, ile razy występuje zakleszczenie. Ponieważ impas może powodować błędy dla zapytań, które w innym przypadku by nie wystąpiły, dobrze jest to śledzić i upewnić się, że aplikacje nie nadepną sobie nawzajem.
Czasy odczytu i zapisu
Kolumny blk_read_time i blk_write_time śledzą całkowitą liczbę milisekund, które backendy w bazie danych spędzają na odczytywaniu i zapisywaniu danych, co może być pomocne przy próbie porównania/poprawy szybkości odczytu/zapisu dysku
Resetowanie statystyk
Ta kolumna, stats_reset, pokazuje po prostu znacznik czasu (ze strefą czasową) ostatniego zresetowania statystyk wymienionych w tym wierszu. Wartość null oznacza, że nie zostały zresetowane od momentu powstania, a nawet prawdopodobnie awaria bazy danych, co mogło wymazać te statystyki.
Punkty kontrolne i autor tła
pg_stat_bgwriter
postgres=# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 47829
checkpoints_req | 2
checkpoint_write_time | 7323
checkpoint_sync_time | 38
buffers_checkpoint | 76
buffers_clean | 0
maxwritten_clean | 0
buffers_backend | 5
buffers_backend_fsync | 0
buffers_alloc | 440
stats_reset | 2018-02-04 19:52:34.712832+00Klaster PostgtreSQL zarządza zapisywaniem danych na dysku na kilka różnych sposobów. Jeśli chodzi o „brudne bufory” (dane w pamięci, które zostały zmienione od czasu odczytania z dysku, ale jeszcze nie zostały zapisane na dysku), jest to wykonywane albo przez punkt kontrolny, albo przez zapis w tle. Ponieważ brudny bufor musi zostać zapisany na dysku, zanim będzie można go zwolnić lub ponownie przydzielić, upewnienie się, że te procesy są precyzyjnie dostrojone, ma kluczowe znaczenie, a ta tabela pomaga rzucić światło na to, jak to wszystko działa.
Punkty kontrolne
Punkt kontrolny występuje zgodnie z harmonogramem (reprezentowanym przez parametr checkpoint_timeout) lub gdy maksymalna liczba plików WAL została użyta od ostatniego punktu kontrolnego i musi wymusić punkt kontrolny. Tak czy inaczej, punkt kontrolny zapisuje brudne bufory na dysku i śledzą go cztery kolumny.
Kolumny checkpoints_timed i checkpoints_req pokazują liczbę zaplanowanych punktów kontrolnych występujących (określonych w czasie) oraz liczbę żądanych punktów kontrolnych (określanych również jako wymuszone). Wysoka wartość wspinaczki checkpoint_req może sugerować niewystarczającą wartość max_wal_size.
Kolumny checkpoint_write_time i checkpoint_sync_time rejestrują całkowity czas (w milisekundach), jaki proces punktu kontrolnego spędził na zapisie i synchronizacji na dysku.
Wreszcie, buffers_checkpoint to całkowita liczba buforów zapisanych na dysku przez punkty kontrolne.
Pisarz w tle
Zapisujący w tle jest oddzielnym procesem, który zapisuje brudne bufory na dysku, co idealnie zmniejsza ilość pracy, jaką musi wykonać wskaźnik kontrolny.
Kolumna buffers_clean reprezentuje liczbę buforów zapisanych na dysku przez proces w tle. W porównaniu do buffers_checkpoint, pokazuje, jaka część obciążenia jest obsługiwana przez każdy proces (z dodatkową wiedzą, że zapisujący w tle ma możliwość wielokrotnego zapisywania buforów, jeśli zmieniają się one często, w przeciwieństwie do rzadszych w przypadku czasowego punktu kontrolnego).
Maxwritten_clean określa, ile razy program zapisujący w tle osiągnął maksymalną liczbę stron do opróżnienia przy każdym uruchomieniu (kontrolowane za pomocą parametru bgwriter_lru_maxpages).
Bufory ogólnie
Pozostałe kolumny pokazują nam ogólne informacje o buforze, przy czym buffers_backend to liczba buforów, które backend musiał napisać sam, zamiast programu do zapisywania w tle lub wskaźnika kontrolnego, buffers_backend_fsync to liczba, ile razy backend musiał wykonać własne wywołanie fsync, oraz buffers_alloc pokazuje ogólną liczbę buforów, które zostały przydzielone.
Aktywność i blokady bazy danych
Istnieją dwa widoki, które pokazują bieżącą aktywność użytkownika, pg_stat_activity i pg_locks. Po zapytaniu wyświetlają one informacje o bieżących połączeniach z bazami danych i rodzajach blokad w jakich relacjach.
pg_stat_activity
postgres=# SELECT * FROM pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid | 13805
datname | severalnines
pid | 29730
usesysid | 10
usename | postgres
application_name | psql
client_addr |
client_hostname |
client_port | -1
backend_start | 2018-07-21 02:29:48.976588+00
xact_start | 2018-07-21 02:30:03.73683+00
query_start | 2018-07-21 02:30:03.73683+00
state_change | 2018-07-21 02:30:03.736835+00
wait_event_type |
wait_event |
state | active
backend_xid |
backend_xmin | 559
query | SELECT first_name FROM customers WHERE customers_sid = 472;
backend_type | client backendInformacje ogólne
Widok pg_stat_activity pokazuje wiersz dla każdego połączenia z bazą danych oraz kilka podstawowych informacji na jego temat. Kolumna dataname reprezentuje bazę danych, z którą połączenie jest aktualnie połączone, pid jest identyfikatorem procesu połączenia na hoście bazy danych, a usesysid i usename reprezentują połączonego użytkownika bazy danych.
Jako źródło klienta client_addr to adres IP hosta, z którego nadeszło połączenie, null oznacza, że jest to lokalne połączenie z gniazdem unix.
sygnatury czasowe
Istnieją cztery kolumny sygnatury czasowej, które pokazują, kiedy pewne rzeczy się zaczęły:backend_start oznacza, że połączenie zostało faktycznie ustanowione, xact_start oznacza rozpoczęcie bieżącej transakcji (null, jeśli klient nie ma otwartej transakcji), query_start oznacza rozpoczęcie bieżącego lub ostatniego zapytania, a state_change to czas ostatniej zmiany stanu połączenia.
Stan połączenia
Ostatnie bity pg_stat_activity obejmują rzeczywisty stan połączenia. Jeśli zapytanie czeka na inne, aby zwolnić blokady, wait_event_type zawiera informacje o rodzaju zdarzenia oczekiwania, a kolumna wait_event pokaże nazwę zdarzenia oczekiwania. To długa lista, ale więcej informacji można znaleźć w dokumentacji PostgreSQL.
Wreszcie kolumna „stan” pokazuje, w jakim stanie znajduje się bieżące połączenie, na przykład aktywne, bezczynne, bezczynne w transakcji, a kolumna zapytań pokaże aktualnie uruchomione lub ostatnio uruchomione zapytanie.
pg_lock
SELECT * FROM pg_locks;
-[ RECORD 1 ]------+----------------
locktype | virtualxid
database |
relation |
page |
tuple |
virtualxid | 3/475862
transactionid |
classid |
objid |
objsubid |
virtualtransaction | 3/475862
pid | 29730
mode | ExclusiveLock
granted | t
fastpath | tTabela pg_locks działa w parze z pg_stat_activity, jeśli przyjrzymy się aktywności zapytań. Za każdym razem, gdy tworzy się blokadę w relacji, ta informacja jest przechowywana w pg_locks. Używając pid z pg_stat_activity, możemy zapytać pg_locks, aby zobaczyć, na jakie relacje połączenie może mieć blokady, jakie to są blokady i czy blokady zostały przyznane.
Najważniejsze kolumny to 'pid', który odpowiada pidowi z pg_stat_activity, 'relation', który pasuje do OID z pg_class, 'mode' pokazujący nazwę utrzymywanego trybu blokady i 'granted', który określa, czy blokada w pytanie zostało przyznane.
Informacje o replikacji
Ponieważ PostgreSQL ma wbudowane funkcje replikacji, istnieje kilka poglądów, które rzucają światło na wydajność i stan samej replikacji.
Wyświetl pg_stat_replication: zawiera wiersz dla każdego procesu nadawcy WAL, zawierający informacje o jego stanie, lokalizacji plików WAL, nad którymi pracuje, oraz informacje o połączeniu hosta w trybie gotowości, który odbiera dane WAL do replikacji.
Wyświetl pg_stat_wal_receiver: Jeśli klaster jest w stanie gotowości, będzie zawierał pojedynczy wiersz pokazujący statystyki dotyczące procesu odbierającego z hosta.
Wyświetl pg_stat_subscription: Jeśli wysyłasz dane WAL do węzła gotowości, każdy wiersz tutaj będzie reprezentował tę subskrypcję i zawierał informacje o stanie subskrypcji.
Wyświetl pg_replication_slots: Zawiera listę wszystkich gniazd replikacji istniejących w klastrze oraz ich aktualny stan.
Metadane specyficzne dla bazy danych
Wewnątrz każdej bazy danych znajduje się zbiór tabel katalogu, które zawierają informacje specyficzne dla bazy danych, której dotyczy zapytanie. Jeśli szukamy konkretnych danych z tych tabel, musimy upewnić się, że podczas wysyłania zapytań jesteśmy połączeni z właściwą bazą danych.
W tym miejscu może pojawić się sedno analizy danych, gdzie możemy zobaczyć, w jaki sposób uzyskujemy dostęp do naszych danych użytkownika. Od tabel, przez indeksy, po sekwencje, zapytania, które przychodzą do bazy danych i pobierają lub modyfikują dane, ich działania i wpływ będą przechowywane w tych tabelach, a my możemy spojrzeć na te informacje, aby podejmować świadome decyzje dotyczące zarządzania bazą danych w dół droga.
Metadane tabeli
Metadane dotyczące naszych tabel użytkowników są przechowywane w następujących dwóch tabelach, a każda z nich ma wiersz dla każdej tabeli użytkownika utworzonej w systemie. Tabela pg_stat_user_tables zawiera statystyki dotyczące dostępu użytkowników do tabeli, podczas gdy pg_statio_user_tables zawiera statystyki we/wy dla każdej tabeli.
UWAGA:Dane tutaj nie zawsze są w 100% doskonałe, a ich poprawność opiera się na częstych analizach tabel. Autoanaliza obejmuje to, ale dobre dostrojenie procesu autoanalizy, aby mógł zachować dobre statystyki dotyczące każdej tabeli. Jeśli statystyki wydają się być wyłączone, ręczne uruchomienie ANALIZY na stole odświeży je.
Tabela pg_stat_user_tables:
severalnines=> SELECT * FROM pg_stat_user_tables WHERE schemaname = 'public' AND relname = 'history';
-[ RECORD 1 ]-------+---------
relid | 2766788
schemaname | public
relname | history
seq_scan | 13817
seq_tup_read | 466841
idx_scan | 12251
idx_tup_fetch | 127652
n_tup_ins | 11
n_tup_upd | 13
n_tup_del | 3
n_tup_hot_upd | 13
n_live_tup | 3
n_dead_tup | 21
n_mod_since_analyze | 19
last_vacuum |
last_autovacuum |
last_analyze |
last_autoanalyze |
vacuum_count | 0
autovacuum_count | 0
analyze_count | 0
autoanalyze_count | 0W przypadku naszych statystyk tabeli użytkowników mamy sporo danych.
Metody dostępu do tabeli
Gdy klienci uzyskują dostęp do danych z tabeli, robią to bezpośrednio lub za pośrednictwem indeksów. Kolumna „seq_scan” zlicza liczbę kolejnych skanowań otrzymanych przez tabelę, a „seq_tup_read” zlicza krotki odczytane przez ten proces. Kolumna „idx_scan” zlicza, ile razy indeks w tabeli został użyty do pobrania danych.
Aktywność dotycząca krotek w tabeli
Mamy teraz kilka kolumn, które liczą różne działania w tabeli.
„n_tup_ins” śledzi liczbę wstawionych krotek
„n_tup_upd” śledzi liczbę zaktualizowanych krotek
„n_tup_del” śledzi liczbę usuniętych krotek
Stan krotki tabeli
Z powodu aktualizacji i usunięcia mogą istnieć martwe krotki, które nie są już aktywnymi danymi, a proces próżniowy ostatecznie je uwolni. Kolumny „n_tup_ins” i „n_tup_ins” śledzą odpowiednio liczbę żywych i martwych krotek. Kiedy martwe krotki osiągną określony punkt, zostanie uruchomiona automatyczna próżnia, w zależności od ustawień automatycznego odkurzania.
Aktywność odkurzania stołu
Obsługa tabeli odbywa się za pomocą VACUUM lub AUTOVACUUM, a statystyki są gromadzone za pomocą funkcji ANALIZA lub AUTOANALIZA. Kolejne cztery kolumny zawierają daty ostatniego uruchomienia każdej z tych operacji:„last_vacuum”, „last_autovacuum”, „last_analyze”, „last_autoanalyze”.
Mamy również cztery wygodniejsze kolumny, które po prostu zliczają, ile razy wystąpiły poprzednie akcje. Korzystając z nich, możemy zobaczyć, które tabele mają największą aktywność:„vacuum_count”, „autovacuum_count”, „analyze_count” i „autoanalyze_count”.
Tabela pg_statio_user_tables:
severalnines=> SELECT * FROM pg_statio_user_tables WHERE schemaname = 'public' AND relname = history;
-[ RECORD 1 ]---+---------
relid | 2766788
schemaname | public
relname | history
heap_blks_read | 4
heap_blks_hit | 63081
idx_blks_read | 5
idx_blks_hit | 44147
toast_blks_read | 0
toast_blks_hit | 0
tidx_blks_read | 0
tidx_blks_hit | 0Wyjście I/O jest przydatne, aby pomóc zrozumieć, w jaki sposób dane są dostępne pod osłonami. Kolumna „heap_blks_read” reprezentuje liczbę bloków dyskowych odczytanych dla tej tabeli, a „heap_blks_hit” reprezentuje bloki bufora odczytane z pamięci w tej tabeli. Jest to pomocne, aby wiedzieć, czy zapytania uzyskujące dostęp do tabeli muszą stale trafiać na dysk, czy też pobierać dane z pamięci.
Statystyki indeksu w tabeli pokazują te same informacje co kolumny „idx_blks_read” i „idx_blks_hit”.
Wreszcie, jeśli tabela zawiera jakiekolwiek tabele TOAST, kolumny „toast_blks_hit” i „toast_blks_read” śledzą tabele toastów, podczas gdy „tdix_blks_read” i „tdix_blks_read” śledzą indeksy tych tabel toastów.
Metadane indeksu
pg_stat_user_indexes
severalnines=> SELECT * FROM pg_stat_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_scan | 43910
idx_tup_read | 98147
idx_tup_fetch | 98147Podobnie jak odpowiedniki tabel, ta tabela zawiera szczegółowe informacje o indeksach. Jeden wiersz na indeks, ta tabela pokazuje, ile razy indeks został zeskanowany za pomocą kolumny „idx_scan”, ile krotek zostało odczytanych za pomocą „idx_tup_read” i ile aktywnych wierszy zostało faktycznie pobranych za pomocą „idx_tup_fetch”.
pg_statio_user_indexes
severalnines=> SELECT * FROM pg_statio_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid | 2766797
indexrelid | 2766934
schemaname | public
relname | history
indexrelname | history_pkey
idx_blks_read | 2
idx_blks_hit | 49380W przypadku pg_statio_user_indexes dwie kolumny dostępne dla danych to „idx_blks_read” i „idx_blks_hit”, reprezentujące liczbę bloków odczytanych z dysku i z pamięci.
Pobierz oficjalny dokument już dziś Zarządzanie i automatyzacja PostgreSQL za pomocą ClusterControlDowiedz się, co musisz wiedzieć, aby wdrażać, monitorować, zarządzać i skalować PostgreSQLPobierz oficjalny dokumentCo możemy zrobić z tymi danymi?
Bądź kreatywny! Jeśli zapytania do określonej tabeli wydają się być bardzo powolne, śledź jej aktywność w czasie, sprawdź, ile sekwencyjnych skanów otrzymuje w porównaniu ze skanami indeksu, sprawdź, czy trafia na dysk, czy do pamięci dla danych.
Jeśli duży stół jest często automatycznie odkurzany, śledź krotki od żywych do martwych w czasie, być może szczególnie wymaga to dostosowania automatycznego odkurzania, aby można go było szybciej ukończyć, a może nawet stół jest kandydatem do partycjonowania.
Ponieważ widzimy, kiedy dane pochodzą z dysku lub pamięci, możemy określić stosunek pamięci do dysku w czasie, wskazując, czy w dowolnym momencie stosunek ten spada w ciągu dnia.
Liczba tabel, które omówiliśmy, przeszła przez duże hity, główne dane, które warto wiedzieć o wewnętrznym działaniu baz danych. Jednak w katalogu systemowym jest znacznie więcej tabel, które zawierają przydatne sytuacyjnie dane. Czytanie innych tabel, jak poprzednio, pomoże uzyskać ogólny wgląd w stan bazy danych.
Aby uzyskać więcej informacji na temat tabel lub widoków w katalogu PostgreSQL, odwiedź oficjalną dokumentację tutaj, a także informacje o kolektorze statystyk tutaj.
