Het beheren van databases is geen geringe taak en kan gemakkelijk frustrerend zijn zonder te weten wat er onder de dekens gebeurt. Of het nu gaat om het uitzoeken of nieuwe indexen nuttig zijn, de transactie op een database op een bepaald moment telt, of wie er op een bepaald moment met de database is verbonden, gegevens waarmee de beheerders echt weten hoe hun databases presteren, zijn koning. Gelukkig zijn met PostgreSQL die gegevens voor dit alles beschikbaar in de PostgreSQL-systeemcatalogus.
De PostgreSQL-systeemcatalogus is een schema met tabellen en weergaven die metagegevens bevatten over alle andere objecten in de database en meer. Hiermee kunnen we ontdekken wanneer verschillende bewerkingen plaatsvinden, hoe tabellen of indexen worden benaderd en zelfs of het databasesysteem informatie uit het geheugen leest of gegevens van schijf moet ophalen.
Hier zullen we een overzicht van de systeemcatalogus doornemen, en aangeven hoe u deze kunt lezen en hoe u er nuttige informatie uit kunt halen. Sommige metadata zijn eenvoudig, en andere stukken vergen een beetje verwerking om echt bruikbare informatie te genereren. Hoe dan ook, PostgreSQL geeft ons een geweldig platform om alle informatie te bouwen die we nodig hebben over de database zelf.
De PostgreSQL-catalogus
PostgreSQL slaat de metadata-informatie over de database en het cluster op in het schema 'pg_catalog'. Deze informatie wordt gedeeltelijk door PostgreSQL zelf gebruikt om dingen zelf bij te houden, maar het wordt ook gepresenteerd zodat externe mensen / processen ook de binnenkant van de databases kunnen begrijpen.
De PostgreSQL-catalogus heeft een behoorlijk solide regel:kijk, raak niet aan. Hoewel PostgreSQL al deze informatie in tabellen opslaat zoals elke andere toepassing zou doen, worden de gegevens in de tabellen volledig beheerd door PostgreSQL zelf en mogen ze niet worden gewijzigd, tenzij in een absoluut noodgeval, en zelfs dan is een herbouw achteraf waarschijnlijk in orde.
We zullen een paar handige catalogustabellen bespreken, hoe de gegevens te lezen en slimme dingen die we met de gegevens zelf kunnen doen. Er zijn nogal wat tabellen in de catalogus die we niet zullen bespreken, maar alle informatie voor deze verschillende tabellen is te vinden in de officiële documentatie van PostgreSQL.
Systeembrede metagegevens
Een groot deel van de tabellen die we in de catalogus kunnen doorzoeken, zijn 'systeembrede' tabellen, waarbij het niet uitmaakt met welke database we zijn verbonden, de gegevens vertegenwoordigen het hele cluster, geen enkele database.
Database-informatie
Algemene database-informatie wordt opgeslagen in pg_database en statistieken worden opgeslagen in 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 |De tabel pg_database bevat een rij voor elke database in het cluster, inclusief de drie die uit de doos komen (postgres, template0 en template1). Deze rij bevat informatie over codering, verbindingslimiet en andere basismetadata.
Interessante kolommen:
oid - De object-ID, die niet wordt weergegeven in een query-uitvoer, tenzij er rechtstreeks naar wordt verwezen. Dit nummer komt overeen met een map in de clustergegevensmap
datname - De naam van de database.
datdba - De eigenaar van de database, oid-referenties pg_authid .oid.
codering - De tekencodering voor deze database, pg_encoding_to_char() wordt geconverteerd naar een leesbare naam.
datconnlimit - Het maximum aantal gelijktijdige verbindingen dat is toegestaan op de database.
dattablespace - De standaard tablespace voor deze database, referenties 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+00In deze statistische tabel krijgen we interessante en nuttige gegevens. Elke rij in deze tabel bevat live gegevens voor elke database en kan periodiek worden geëxporteerd om in de loop van de tijd te worden gevolgd als u wijzigingen wilt controleren.
Transacties
Transactie-informatie is te vinden in de kolommen xact_commit en xact_rollback, die respectievelijk het aantal transacties bevatten dat de database heeft vastgelegd en teruggedraaid. Dit zal helpen om te laten zien hoe actief een database is, en om mogelijke fouten op te sporen met programma's die in een alarmerend tempo fouten maken / terugdraaien.
Schijf- en geheugentoegang
Informatie over het al dan niet ophalen van gegevens van schijf of geheugen wordt opgeslagen in de kolommen blks_read en blks_hit. Blks_read toont het aantal blokken dat deze database van schijf heeft gelezen, terwijl blks_hit het aantal blokken toont dat werd gevonden in de buffercache van PostgreSQL (weergegeven door de parameter shared_buffers). Aangezien RAM veel sneller is dan schijf, zouden we idealiter blks_hit consequent hoger zien dan blks_read, en zo niet, dan kunnen we ons beschikbare geheugen opnieuw evalueren.
Tuples
De volgende kolommen gaan over tupels. Tup_returned is het aantal rijen dat wordt geretourneerd in de database, wat het aantal rijen is dat wordt gelezen door opeenvolgende scans als het uit een tabel komt, of het aantal indexitems dat wordt geretourneerd wanneer het uit een index komt”. Tup_fetched is het aantal rijen dat in de database is opgehaald, wat betekent dat ze het resultaat waren van bitmapscans, wat het aantal tabelrijen is dat is opgehaald door bitmapscans als uit een tabel, of tabelrijen opgehaald door eenvoudige indexscans als een index wordt gebruikt.
We hebben ook tup_inserted, tup_updated en tup_deleted, die respectievelijk het aantal tuples vertegenwoordigen dat in deze database is ingevoegd, bijgewerkt en verwijderd. Dit zal helpen begrijpen hoe gegevens de database binnenkomen, wijzigen en verlaten. Aangezien bijgewerkte en verwijderde tuples resulteren in dode rijen, suggereren hoge waarden in deze kolommen dat autovacuümbewerkingen worden afgestemd op de behoeften van de database-activiteit.
Conflicten
Als de database in kwestie een standby-server is, zijn de kolomconflicten handig om bij te houden hoeveel query's zijn geannuleerd vanwege conflicten met de standby-modus in de 'herstelmodus'. Als het geen standby-cluster is, kan deze kolom worden genegeerd.
Tijdelijke bestanden/gegevens
Soms moeten query's naar tijdelijke bestanden worden geschreven. Dit kan gebeuren wanneer de hoeveelheid work_mem die aan de verbinding is toegewezen, is opgebruikt en een sorteerbewerking op schijf moet voortzetten in plaats van in het geheugen. De kolom temp_files houdt het aantal van deze bestanden bij dat is gemaakt, en temp_bytes houdt de totale grootte bij van alle gebruikte tijdelijke bestanden. Deze gegevens kunnen helpen bij het afstemmen van work_mem, of zelfs bij het vinden van zoekopdrachten die herschreven kunnen worden als de grootte van het tijdelijke bestand te groot is.
Vastgelopen
De kolom deadlocks houdt bij hoe vaak een deadlock optreedt. Aangezien een impasse fouten kan veroorzaken voor zoekopdrachten die anders niet zouden optreden, is het goed om dit bij te houden en ervoor te zorgen dat applicaties elkaar niet op de hielen zitten.
Lees- en schrijftijden
De kolommen blk_read_time en blk_write_time houden het totale aantal milliseconden bij dat backends in de database besteden aan het lezen en schrijven van gegevens, wat handig kan zijn bij het vergelijken / verbeteren van de lees-/schrijfsnelheid van de schijf
Statistieken resetten
Deze kolom, stats_reset, toont eenvoudig een tijdstempel (met tijdzone) van de laatste keer dat de statistieken in deze rij zijn gereset. Een null-waarde betekent dat ze niet opnieuw zijn ingesteld sinds het begin, of zelfs mogelijk een crash van de database waardoor deze statistieken mogelijk zijn weggevaagd.
Checkpoints en de achtergrondschrijver
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+00Het PostgtreSQL-cluster beheert het schrijven van gegevens naar schijf op verschillende manieren. In termen van 'vuile buffers' (gegevens in het geheugen die zijn gewijzigd sinds ze van schijf zijn gelezen, maar die wijziging nog naar schijf moeten worden geschreven), wordt dit gedaan door een controlepunt of de achtergrondschrijver. Aangezien een vuile buffer naar de schijf moet worden geschreven voordat deze kan worden vrijgemaakt of opnieuw kan worden toegewezen, is het van cruciaal belang ervoor te zorgen dat deze processen nauwkeurig worden afgestemd, en deze tabel helpt licht te werpen op hoe het allemaal werkt.
Checkpoints
Een controlepunt vindt plaats op schema (weergegeven door de parameter checkpoint_timeout), of wanneer het maximale aantal WAL-bestanden is gebruikt sinds het laatste controlepunt en een controlepunt moet worden geforceerd. Hoe dan ook, een controlepunt schrijft vuile buffers naar de schijf en er zijn vier kolommen die het volgen.
De kolommen checkpoints_timed en checkpoints_req laten het aantal geplande checkpoints zien (timed) en het aantal aangevraagde checkpoints (ook wel geforceerd genoemd). Een hoge klimwaarde van checkpoint_req kan duiden op een onvoldoende max_wal_size waarde.
De kolommen checkpoint_write_time en checkpoint_sync_time registreren de totale hoeveelheid tijd (in milliseconden) die het checkpointproces heeft besteed aan het schrijven en synchroniseren naar schijf.
Ten slotte is buffers_checkpoint het totale aantal buffers dat door checkpoints naar schijf is geschreven.
Achtergrondschrijver
De achtergrondschrijver is een apart proces dat vuile buffers naar schijf schrijft, wat idealiter de hoeveelheid werk die de checkpointer moet doen, vermindert.
De kolom buffers_clean vertegenwoordigt het aantal buffers dat door het achtergrondproces naar schijf is geschreven. In vergelijking met buffers_checkpoint, laat het zien hoeveel van de werklast door elk proces wordt afgehandeld (met de toegevoegde kennis dat een achtergrondschrijver de mogelijkheid heeft om buffers meerdere keren te schrijven als ze vaak veranderen, versus minder vaak met een getimed checkpoint).
Maxwritten_clean vertegenwoordigt het aantal keren dat de achtergrondschrijver het maximale aantal pagina's heeft bereikt om te wissen elke keer dat deze wordt uitgevoerd (gecontroleerd met de parameter bgwriter_lru_maxpages).
Buffers in het algemeen
De overige kolommen tonen ons de algemene bufferinformatie, waarbij buffers_backend het aantal buffers is dat een backend zelf moest schrijven, in plaats van achtergrondschrijver of checkpointer, buffers_backend_fsync is een telling van hoe vaak een backend zijn eigen fsync-aanroep moest uitvoeren, en buffers_alloc toont het aantal buffers dat in het algemeen is toegewezen.
Databaseactiviteit en vergrendelingen
Er zijn twee weergaven die de huidige gebruikersactiviteit tonen, pg_stat_activity en pg_locks. Wanneer ze worden opgevraagd, tonen deze informatie over de huidige verbindingen met de databases en wat voor soort vergrendelingen ze hebben op welke relaties.
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 backendAlgemene informatie
De weergave pg_stat_activity toont een rij voor elke verbinding met de database en wat basisinformatie erover. De kolom datname vertegenwoordigt de database waarmee de verbinding daadwerkelijk is verbonden, pid is de proces-ID van de verbinding op de databasehost zelf, en usesysid en usename vertegenwoordigen de verbonden databasegebruiker.
Voor de bron van de client is client_addr het IP-adres van de host waar de verbinding vandaan kwam, null betekent dat het een lokale unix-socketverbinding is.
Tijdstempels
Er zijn vier tijdstempelkolommen die aangeven wanneer bepaalde dingen zijn begonnen:backend_start is wanneer de verbinding daadwerkelijk tot stand is gebracht, xact_start is wanneer de huidige transactie is gestart (null als de klant geen openstaande transactie heeft), query_start is wanneer de huidige of meest recente zoekopdracht is gestart, en state_change is het tijdstip waarop de status van de verbinding voor het laatst is gewijzigd.
Verbindingsstatus
De laatste stukjes van pg_stat_activity hebben betrekking op de actuele status van de verbinding. Als de query op een andere wacht om vergrendelingen vrij te geven, bevat wait_event_type informatie over wat voor soort wait-gebeurtenis het is, en de kolom wait_event toont de naam van de wait-gebeurtenis. Het is een lange lijst, maar meer informatie is te vinden in de PostgreSQL-documentatie.
Ten slotte geeft de kolom 'state' weer in welke staat de huidige verbinding zich bevindt, zoals actief, inactief, inactief in transactie, en de querykolom toont de daadwerkelijke query die wordt uitgevoerd of meest recentelijk is uitgevoerd.
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 | tDe pg_locks-tabel werkt hand in hand met pg_stat_activity bij het onderzoeken van query-activiteit. Elke keer dat een relatie wordt vergrendeld, wordt die informatie opgeslagen in pg_locks. Met behulp van de pid van pg_stat_activity kunnen we pg_locks opvragen om te zien op welke relaties een verbinding mogelijk vergrendelingen heeft, wat voor soort vergrendelingen dat zijn en of de vergrendelingen al dan niet zijn verleend.
De belangrijkste kolommen zijn 'pid', die overeenkomt met de pid van pg_stat_activity, 'relation' die overeenkomt met de OID van pg_class, 'mode' met de naam van de vastgehouden vergrendelingsmodus en 'toegekend' die aangeeft of de vergrendeling in vraag is ingewilligd.
Replicatie-info
Aangezien PostgreSQL ingebouwde replicatiefuncties heeft, zijn er enkele weergaven die licht werpen op de prestaties en status van de replicatie zelf.
Bekijk pg_stat_replicatie: bevat een rij voor elk WAL-verzendproces, met informatie over de status, de locatie van de WAL-bestanden waaraan het werkt en de verbindingsinformatie van de standby-host die de WAL-gegevens ontvangt voor replicatie.
Bekijk pg_stat_wal_receiver: Als de cluster een stand-by is, bevat deze een enkele rij met statistieken over het ontvangstproces van de host.
Bekijk pg_stat_subscription: Als WAL-gegevens naar een standby-knooppunt worden verzonden, vertegenwoordigt elke rij hier dat abonnement en bevat het informatie over de status van de abonnementen.
Bekijk pg_replication_slots: Bevat een lijst van alle replicatieslots die in het cluster aanwezig zijn, en hun huidige status.
Databasespecifieke metadata
Binnen elke database is er een verzameling catalogustabellen die informatie bevatten die specifiek is voor de database die wordt opgevraagd. Als we op zoek zijn naar specifieke gegevens uit deze tabellen, moeten we ervoor zorgen dat we zijn verbonden met de juiste database als we de query's uitvoeren.
Dit is waar het hart van data-analyse kan komen, waar we kunnen zien hoe onze gebruikersgegevens worden benaderd. Van tabellen tot indexen tot sequenties, de zoekopdrachten die in de database binnenkomen en gegevens ophalen of wijzigen, hun acties en impact zullen in deze tabellen worden opgeslagen, en we kunnen naar die informatie kijken om weloverwogen beslissingen te nemen over het beheer van de database in de weg.
Tabelmetadata
Metagegevens over onze gebruikerstabellen worden opgeslagen in de volgende twee tabellen en ze hebben elk een rij voor elke gebruikerstabel die in het systeem is gemaakt. De tabel pg_stat_user_tables bevat statistieken over gebruikerstoegang tot de tabel, terwijl pg_statio_user_tables I/O-statistieken voor elke tabel bevat.
OPMERKING:de gegevens hier zijn niet altijd 100% perfect en zijn afhankelijk van frequente analyses van de tabellen om correct te zijn. Autoanalyse dekt dit, maar een goede afstemming van het autoanalyseproces zodat het goede statistieken over elke tabel kan bijhouden. Als de statistieken niet lijken te kloppen, zal het handmatig uitvoeren van een ANALYSE op de tafel ze vernieuwen.
Tabel 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 | 0Voor onze gebruikerstabelstatistieken hebben we nogal wat gegevens.
Tabeltoegangsmethoden
Wanneer clients toegang krijgen tot gegevens uit de tabel, gebeurt dit rechtstreeks of via indexen. De kolom 'seq_scan' telt het aantal opeenvolgende scans dat de tabel heeft ontvangen, en 'seq_tup_read' telt het aantal tuples dat door dat proces is gelezen. De kolom 'idx_scan' telt hoe vaak een index op de tabel is gebruikt om gegevens op te halen.
Table Tuple-activiteit
We hebben nu een handvol kolommen die verschillende activiteiten tellen op de tafel.
'n_tup_ins' houdt het aantal ingevoegde tuples bij
'n_tup_upd' houdt het aantal bijgewerkte tuples bij
'n_tup_del' houdt het aantal verwijderde tuples bij
Tabel Tuple-status
Vanwege updates en verwijderingen kunnen er dode tupels zijn die niet langer actieve gegevens zijn, en het vacuümproces zal ze uiteindelijk vrijmaken. De kolommen 'n_tup_ins' en 'n_tup_ins' volgen het aantal tupels dat respectievelijk levend en dood is. Wanneer dode tupels een bepaald punt bereiken, wordt een autovacuüm gestart, afhankelijk van de autovacuüm-instellingen.
Tafelvacuümactiviteit
Tabelonderhoud wordt gedaan via VACUUM of AUTOVACUUM, en statistieken worden verzameld via ANALYZE of AUTOANALYZE. De volgende vier kolommen bevatten de datums waarop elk van deze bewerkingen voor het laatst is uitgevoerd:'last_vacuum', 'last_autovacuum', 'last_analyze', 'last_autoanalyze'.
We hebben ook vier handigere kolommen die eenvoudig tellen hoe vaak de vorige acties plaatsvinden. Hiermee kunnen we zien welke tabellen de meeste activiteit krijgen:'vacuum_count', 'autovacuum_count', 'analyze_count' en 'autoanalyze_count'.
Tabel 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 | 0De I/O-uitgang is handig om te helpen begrijpen hoe de gegevens onder de dekens worden benaderd. De kolom 'heap_blks_read' vertegenwoordigt het aantal schijfblokken dat voor deze tabel is gelezen, en 'heap_blks_hit' vertegenwoordigt de bufferblokken die in deze tabel uit het geheugen worden gelezen. Dit is handig om te weten of query's die toegang krijgen tot de tabel constant naar de schijf moeten gaan of de gegevens uit het geheugen moeten halen.
Indexstatistieken in de tabel tonen dezelfde informatie met de kolommen 'idx_blks_read' en 'idx_blks_hit'.
Als de tabel TOAST-tabellen heeft, volgen de kolommen 'toast_blks_hit' en 'toast_blks_read' toasttabellen, terwijl 'tdix_blks_read' en 'tdix_blks_read' de indexen op die toasttabellen volgen.
Indexmetagegevens
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 | 98147Net als de tegenhangers van de tabel bevat deze tabel specifiek informatie over de indexen. Eén rij per index, deze tabel laat zien hoe vaak de index is gescand met de kolom 'idx_scan', hoeveel tuples zijn gelezen met 'idx_tup_read' en hoeveel live rijen er daadwerkelijk zijn opgehaald met '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 | 49380Voor pg_statio_user_indexes zijn de twee kolommen die beschikbaar zijn voor gegevens 'idx_blks_read' en 'idx_blks_hit', die het aantal blokken vertegenwoordigen dat van schijf en uit geheugen wordt gelezen.
Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaperWat kunnen we met deze gegevens doen?
Wees creatief! Als zoekopdrachten naar een specifieke tabel extreem traag lijken, volg dan de activiteit in de loop van de tijd, kijk hoeveel opeenvolgende scans het krijgt versus indexscans, kijk of het naar schijf of geheugen gaat voor de gegevens.
Als een grote tafel regelmatig geautovacuümeerd wordt, volg dan de levend tot dode tupels in de loop van de tijd, misschien moet het autovacuüm specifiek worden aangepast zodat het sneller kan worden voltooid, of misschien is de tafel een kandidaat voor partitionering.
Omdat we kunnen zien wanneer gegevens van schijf of geheugen komen, kunnen we in de loop van de tijd een verhouding tussen geheugen en schijf creëren, om te bepalen of de verhouding op enig moment in de loop van de dag daalt.
Het aantal tabellen dat we hebben behandeld, ging over de grote hitters, de belangrijkste gegevens die nuttig zijn om te weten over de interne werking van de databases. Er zijn echter veel meer tabellen in de systeemcatalogus die situationeel bruikbare gegevens bevatten. Het lezen van andere tabellen zoals eerder zal helpen om inzicht te krijgen in de gezondheid van de database in het algemeen.
Voor meer informatie over tabellen of weergaven in de PostgreSQL-catalogus, bezoek hier de officiële documentatie, evenals informatie over de statistiekenverzamelaar hier.