Mengelola database bukanlah tugas kecil, dan dapat dengan mudah membuat frustrasi tanpa mengetahui apa yang terjadi di balik selimut. Baik mencoba mencari tahu apakah indeks baru membantu, jumlah transaksi pada basis data pada waktu tertentu, atau siapa yang terhubung ke basis data pada waktu tertentu, data yang memungkinkan administrator benar-benar mengetahui kinerja basis data mereka adalah rajanya. Untungnya, dengan PostgreSQL, data untuk semua ini tersedia di katalog sistem PostgreSQL.
Katalog Sistem PostgreSQL adalah skema dengan tabel dan tampilan yang berisi metadata tentang semua objek lain di dalam database dan banyak lagi. Dengannya, kita dapat mengetahui kapan berbagai operasi terjadi, bagaimana tabel atau indeks diakses, dan bahkan apakah sistem database membaca informasi dari memori atau tidak atau perlu mengambil data dari disk.
Di sini kita akan membahas ikhtisar katalog sistem, dan menyoroti cara membacanya, dan cara menarik informasi yang berguna darinya. Beberapa metadata sangat mudah, dan bagian lain membutuhkan sedikit proses untuk menghasilkan informasi yang benar-benar berguna. Bagaimanapun, PostgreSQL memberi kita platform hebat untuk membangun informasi apa pun yang kita butuhkan tentang database itu sendiri.
Katalog PostgreSQL
PostgreSQL menyimpan informasi metadata tentang database dan cluster dalam skema 'pg_catalog'. Informasi ini sebagian digunakan oleh PostgreSQL sendiri untuk melacak hal-hal itu sendiri, tetapi juga disajikan sehingga orang/proses eksternal dapat memahami bagian dalam database juga.
Katalog PostgreSQL memiliki aturan yang cukup solid:Lihat, jangan sentuh. Meskipun PostgreSQL menyimpan semua informasi ini dalam tabel seperti aplikasi lainnya, data dalam tabel sepenuhnya dikelola oleh PostgreSQL itu sendiri, dan tidak boleh dimodifikasi kecuali keadaan darurat mutlak, dan bahkan pembangunan kembali mungkin dilakukan setelahnya.
Kita akan membahas beberapa tabel katalog yang berguna, cara membaca data, dan hal-hal cerdas yang dapat kita lakukan dengan data itu sendiri. Ada beberapa tabel dalam katalog yang tidak akan kita bahas, tetapi semua informasi untuk berbagai tabel ini dapat ditemukan di dokumentasi resmi PostgreSQL.
Metadata Seluruh Sistem
Sebagian besar tabel yang dapat kita kueri dalam katalog adalah tabel 'lebar sistem', di mana tidak peduli database mana yang terhubung dengan kita, data mewakili seluruh cluster, tidak ada database tunggal.
Informasi Basis Data
Info database umum disimpan di pg_database dan statistik disimpan di 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 |Tabel pg_database berisi baris untuk setiap database di cluster, termasuk tiga yang keluar dari kotak (postgres, template0, dan template1). Baris ini berisi informasi untuk encoding, batas koneksi, dan metadata dasar lainnya.
Kolom minat:
oid - Pengidentifikasi objek, yang tidak muncul dalam output kueri kecuali direferensikan secara langsung. Nomor ini akan cocok dengan direktori di direktori data cluster
datname - Nama database.
datdba - Pemilik database, referensi oid pg_authid .oid.
encoding - Pengkodean karakter untuk database ini, pg_encoding_to_char() akan dikonversi ke nama yang dapat dibaca.
datconnlimit - Jumlah maksimum koneksi bersamaan yang diizinkan di database.
dattablespace - The tablespace default untuk database ini, referensi 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+00Tabel stat ini adalah tempat kita mendapatkan data yang menarik dan berguna. Setiap baris dalam tabel ini berisi data langsung untuk setiap database, dan dapat diekspor secara berkala untuk dilacak dari waktu ke waktu jika ingin memantau perubahan.
Transaksi
Informasi transaksi dapat ditemukan di kolom xact_commit dan xact_rollback, yang masing-masing berisi jumlah transaksi yang telah dilakukan database dan dibatalkan. Ini akan membantu menunjukkan seberapa aktif database, serta menemukan kemungkinan kegagalan dengan program yang mungkin error / mundur pada tingkat yang mengkhawatirkan.
Akses Disk dan Memori
Informasi diambil atau tidaknya data dari disk atau memori disimpan di kolom blks_read dan blks_hit. Blks_read menunjukkan jumlah blok yang dibaca database ini dari disk, sedangkan blks_hit menunjukkan jumlah blok yang ditemukan di cache buffer PostgreSQL (diwakili oleh parameter shared_buffers). Karena RAM jauh lebih cepat daripada disk, idealnya kita melihat blks_hit secara konsisten lebih tinggi daripada blks_read, dan jika tidak, kita dapat mengevaluasi kembali memori yang tersedia.
Tuple
Beberapa kolom berikutnya berurusan dengan tupel. Tup_returned adalah jumlah baris yang dikembalikan dalam database, yang merupakan jumlah baris yang dibaca oleh pemindaian berurutan jika dari tabel, atau jumlah entri indeks yang dikembalikan saat dari indeks”. Tup_fetched adalah jumlah baris yang diambil dalam database, artinya baris tersebut adalah hasil dari pemindaian bitmap, yaitu jumlah baris tabel yang diambil dengan pemindaian bitmap jika dari sebuah tabel, atau baris tabel yang diambil dengan pemindaian indeks sederhana jika menggunakan indeks.
Kami juga memiliki tup_inserted, tup_updated, dan tup_deleted, yang masing-masing mewakili jumlah tupel yang dimasukkan, diperbarui, dan dihapus dalam database ini. Ini akan membantu memahami bagaimana data masuk, berubah, dan meninggalkan database. Karena tupel yang diperbarui dan dihapus menghasilkan baris mati, nilai tinggi di kolom ini akan menyarankan operasi autovacuum disetel untuk memenuhi kebutuhan aktivitas database.
Konflik
Jika database yang dimaksud adalah server siaga, konflik kolom berguna sebagai cara untuk melacak berapa banyak kueri yang dibatalkan karena konflik dengan siaga dalam 'mode pemulihan'. Jika bukan cluster siaga, kolom ini dapat diabaikan.
File / data sementara
Terkadang, kueri perlu ditulis ke file sementara. Ini dapat terjadi ketika jumlah work_mem yang dialokasikan ke koneksi telah habis, dan perlu melanjutkan operasi pengurutan pada disk daripada di memori. Kolom temp_files melacak jumlah file yang dibuat ini, dan temp_bytes melacak ukuran total semua file sementara yang digunakan. Data ini dapat membantu menginformasikan penyetelan work_mem, atau bahkan menemukan kueri yang dapat menggunakan penulisan ulang jika ukuran file temp terlalu besar.
Deadlock
Kolom kebuntuan melacak berapa kali kebuntuan terjadi. Karena kebuntuan dapat menyebabkan kesalahan untuk kueri yang seharusnya tidak akan salah, sebaiknya lacak ini dan pastikan aplikasi tidak saling menginjak.
Waktu baca dan tulis
Kolom blk_read_time dan blk_write_time melacak jumlah milidetik yang digunakan backend dalam database untuk membaca dan menulis data, yang dapat membantu jika mencoba membandingkan / meningkatkan kecepatan baca/tulis disk
Reset statistik
Kolom ini, stats_reset, hanya menunjukkan stempel waktu (dengan zona waktu) terakhir kali statistik yang disebutkan di baris ini disetel ulang. Nilai nol berarti mereka belum disetel ulang sejak awal, atau bahkan mungkin kerusakan database yang mungkin telah menghapus statistik ini.
Pos Pemeriksaan dan Penulis Latar Belakang
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+00Cluster PostgtreSQL mengelola penulisan data ke disk dengan beberapa cara berbeda. Dalam hal 'buffer kotor' (data dalam memori yang telah diubah sejak dibaca dari disk, tetapi perubahan itu belum ditulis ke disk), ini dilakukan baik oleh pos pemeriksaan, atau penulis latar belakang. Karena buffer kotor harus ditulis ke disk sebelum dapat dibebaskan atau dialokasikan kembali, memastikan proses ini disetel dengan baik sangat penting, dan tabel ini membantu menjelaskan cara kerja semuanya.
Pos pemeriksaan
Pos pemeriksaan terjadi sesuai jadwal (diwakili oleh parameter checkpoint_timeout), atau ketika jumlah maksimum file WAL telah digunakan sejak pos pemeriksaan terakhir, dan perlu memaksa pos pemeriksaan. Either way, pos pemeriksaan menulis buffer kotor ke disk, dan ada empat kolom yang melacaknya.
Kolom checkpoints_timed dan checkpoints_req menunjukkan jumlah checkpoint terjadwal yang terjadi (timed) dan jumlah checkpoint yang diminta (juga disebut sebagai paksa). Nilai checkpoint_req yang tinggi dapat menunjukkan nilai max_wal_size yang tidak mencukupi.
Kolom checkpoint_write_time dan checkpoint_sync_time mencatat jumlah total waktu (dalam milidetik) yang dihabiskan proses pos pemeriksaan untuk menulis dan menyinkronkan ke disk.
Terakhir, buffers_checkpoint adalah jumlah total buffer yang ditulis ke disk oleh pos pemeriksaan.
Penulis Latar Belakang
Penulis latar belakang adalah proses terpisah yang menulis buffer kotor ke disk, yang idealnya mengurangi jumlah pekerjaan yang perlu dilakukan oleh pemeriksa.
Kolom buffers_clean mewakili jumlah buffer yang ditulis ke disk oleh proses latar belakang. Jika dibandingkan dengan buffers_checkpoint, ini menunjukkan berapa banyak beban kerja yang ditangani oleh setiap proses (dengan tambahan pengetahuan bahwa penulis latar memiliki kemungkinan menulis buffer beberapa kali jika mereka sering berubah, vs lebih jarang dengan checkpoint berwaktu).
Maxwritten_clean menunjukkan berapa kali penulis latar belakang mencapai jumlah halaman maksimum untuk dibersihkan setiap kali dijalankan (dikontrol dengan parameter bgwriter_lru_maxpages).
Buffer Secara Umum
Kolom yang tersisa menunjukkan kepada kita informasi buffer umum, dengan buffers_backend menjadi jumlah buffer yang harus ditulis oleh backend sendiri, alih-alih penulis latar belakang atau checkpointer, buffers_backend_fsync adalah hitungan berapa kali backend harus mengeksekusi panggilan fsync-nya sendiri, dan buffers_alloc menunjukkan jumlah buffer yang telah dialokasikan secara umum.
Aktivitas dan Penguncian Basis Data
Ada dua tampilan yang menunjukkan aktivitas pengguna saat ini, pg_stat_activity dan pg_locks. Saat ditanya, ini menunjukkan informasi tentang koneksi saat ini ke database, dan jenis kunci apa yang mereka miliki pada hubungan apa.
pg_stat_aktivitas
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 backendInformasi umum
Tampilan pg_stat_activity menunjukkan baris untuk setiap koneksi ke database, dan beberapa informasi dasar tentangnya. Kolom datname mewakili database tempat koneksi sebenarnya terhubung, pid adalah ID Proses koneksi pada host database itu sendiri, dan usingsysid dan usename mewakili pengguna database yang terhubung.
Untuk sumber klien, client_addr adalah alamat IP dari host asal koneksi, null berarti koneksi soket unix lokal.
Stempel waktu
Ada empat kolom cap waktu yang menunjukkan kapan hal-hal tertentu dimulai:backend_start adalah saat koneksi benar-benar dibuat, xact_start adalah saat transaksi saat ini dimulai (null jika klien tidak memiliki transaksi terbuka), query_start adalah saat kueri saat ini atau terbaru dimulai, dan state_change adalah waktu terakhir kali status koneksi diubah.
Status Koneksi
Bit terakhir pg_stat_activity mencakup status koneksi yang sebenarnya. Jika kueri menunggu yang lain untuk melepaskan kunci, wait_event_type berisi beberapa informasi tentang jenis peristiwa tunggu itu, dan kolom wait_event akan menampilkan nama peristiwa tunggu. Daftarnya panjang, tetapi informasi lebih lanjut dapat ditemukan di dokumentasi PostgreSQL.
Terakhir, kolom 'status' menunjukkan status koneksi saat ini, seperti aktif, tidak aktif, menganggur dalam transaksi, dan kolom kueri akan menampilkan kueri aktual yang sedang dijalankan, atau yang paling baru dijalankan.
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 | tTabel pg_locks bekerja bersama dengan pg_stat_activity jika melihat aktivitas kueri. Setiap kali kunci dibuat untuk suatu relasi, informasi itu disimpan di pg_locks. Menggunakan pid dari pg_stat_activity, kita dapat menanyakan pg_locks untuk melihat hubungan apa yang mungkin dikunci oleh koneksi, jenis kunci apa itu, dan apakah kunci telah diberikan atau tidak.
Kolom yang paling penting adalah 'pid', yang cocok dengan pid dari pg_stat_activity, 'relation' yang cocok dengan OID dari pg_class, 'mode' yang menunjukkan nama mode kunci yang dipegang, dan 'granted' yang menyatakan apakah lock in atau tidak. pertanyaan telah diberikan.
Info Replikasi
Karena PostgreSQL memiliki fitur replikasi bawaan, ada beberapa pandangan yang menjelaskan kinerja dan status replikasi itu sendiri.
Lihat pg_stat_replication: berisi baris untuk setiap proses pengirim WAL, berisi informasi tentang statusnya, lokasi file WAL yang sedang dikerjakannya, dan informasi koneksi dari host siaga yang menerima data WAL untuk replikasi.
Lihat pg_stat_wal_receiver: Jika cluster dalam keadaan standby, ini akan berisi satu baris yang menunjukkan statistik tentang proses penerima dari host.
Lihat pg_stat_subscription: Jika mengirim data WAL ke node siaga, setiap baris di sini akan mewakili langganan tersebut, dan berisi informasi tentang status langganan.
Lihat pg_replication_slots: Berisi daftar semua slot replikasi yang ada di cluster, dan statusnya saat ini.
Metadata Khusus Basis Data
Di dalam setiap database terdapat kumpulan tabel katalog yang memiliki informasi khusus untuk database yang sedang ditanyakan. Jika kita mencari data spesifik dari tabel ini, kita harus memastikan bahwa kita terhubung ke database yang tepat saat kita mengeluarkan kueri.
Di sinilah inti dari analisis data dapat masuk, di mana kita dapat melihat bagaimana data pengguna kita diakses. Dari tabel, hingga indeks, hingga urutan, kueri yang masuk ke database dan mengambil atau mengubah data, tindakan dan dampaknya akan disimpan dalam tabel ini, dan kita dapat melihat informasi tersebut untuk membuat keputusan yang tepat tentang mengelola database di bawah jalan.
Metadata Tabel
Metadata tentang tabel pengguna kami disimpan dalam dua tabel berikut, dan masing-masing tabel memiliki baris untuk setiap tabel pengguna yang dibuat dalam sistem. Tabel pg_stat_user_tables berisi statistik akses pengguna ke tabel, sedangkan pg_statio_user_tables berisi statistik I/O untuk setiap tabel.
CATATAN:Data di sini tidak selalu 100% sempurna, dan bergantung pada analisis tabel yang sering dilakukan agar benar. Analisis otomatis mencakup ini, tetapi penyetelan yang baik dari proses analisis otomatis sehingga dapat menyimpan statistik yang baik tentang setiap tabel. Jika statistik tampaknya tidak aktif, menjalankan ANALYZE secara manual di tabel akan menyegarkannya.
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 | 0Untuk statistik tabel pengguna kami, kami memiliki beberapa bagian data.
Metode Akses Tabel
Ketika klien mengakses data dari tabel, ia melakukannya secara langsung atau melalui indeks. Kolom 'seq_scan' menghitung jumlah pemindaian berurutan yang diterima tabel, dan 'seq_tup_read' menghitung jumlah tupel yang dibaca melalui proses itu. Kolom 'idx_scan' menghitung berapa kali indeks pada tabel digunakan untuk mengambil data.
Aktivitas Tuple Tabel
Kami sekarang memiliki beberapa kolom yang menghitung aktivitas yang berbeda di atas meja.
'n_tup_ins' melacak jumlah tupel yang dimasukkan
‘n_tup_upd’ melacak jumlah tupel yang diperbarui
‘n_tup_del’ melacak jumlah tupel yang dihapus
Status Tuple Tabel
Karena pembaruan dan penghapusan, mungkin ada tupel mati yang bukan lagi data aktif, dan proses vakum pada akhirnya akan membebaskannya. Kolom 'n_tup_ins' dan 'n_tup_ins' melacak jumlah tupel yang hidup dan mati, masing-masing. Ketika tupel mati mencapai titik tertentu, autovacuum akan diluncurkan, tergantung pada pengaturan autovacuum.
Aktivitas Vakum Tabel
Pemeliharaan tabel dilakukan melalui VACUUM atau AUTOVACUUM, dan statistik dikumpulkan melalui ANALYZE atau AUTOANALYZE. Empat kolom berikutnya berisi tanggal kapan masing-masing operasi ini terakhir dijalankan:'last_vacuum', 'last_autovacuum', 'last_analyze', 'last_autoanalyze'.
Kami juga memiliki empat kolom yang lebih nyaman yang hanya menghitung berapa kali tindakan sebelumnya terjadi. Dengan menggunakan ini, kita dapat melihat tabel mana yang mendapatkan aktivitas paling banyak:'vacuum_count', 'autovacuum_count', 'analyze_count', dan '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 | 0Output I/O berguna untuk membantu memahami bagaimana data diakses di bawah selimut. Kolom 'heap_blks_read' mewakili jumlah blok disk yang dibaca untuk tabel ini, dan 'heap_blks_hit' mewakili blok buffer yang dibaca dari memori di tabel ini. Ini berguna untuk mengetahui apakah kueri yang mengakses tabel terus-menerus harus masuk ke disk, atau mengambil data dari memori.
Statistik indeks pada tabel menunjukkan informasi yang sama dengan kolom ‘idx_blks_read’ dan ‘idx_blks_hit’.
Terakhir, jika tabel memiliki tabel TOAST, kolom 'toast_blks_hit' dan 'toast_blks_read' melacak tabel toast, sementara 'tdix_blks_read' dan 'tdix_blks_read' melacak indeks pada tabel toast tersebut.
Metadata Indeks
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 | 98147Sama seperti rekan-rekan tabel, tabel ini berisi informasi tentang indeks secara khusus. Satu baris per indeks, tabel ini menunjukkan berapa kali indeks dipindai dengan kolom 'idx_scan', berapa banyak tupel yang dibaca dengan 'idx_tup_read', dan berapa banyak baris langsung yang benar-benar diambil dengan '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 | 49380Untuk pg_statio_user_indexes, dua kolom yang tersedia untuk data adalah ‘idx_blks_read’, dan ‘idx_blks_hit’, yang menunjukkan jumlah blok yang dibaca dari disk dan dari memori.
Unduh Whitepaper Hari Ini Pengelolaan &Otomatisasi PostgreSQL dengan ClusterControlPelajari tentang apa yang perlu Anda ketahui untuk menerapkan, memantau, mengelola, dan menskalakan PostgreSQLUnduh WhitepaperApa yang bisa kita lakukan dengan data ini?
Menjadi kreatif! Jika kueri ke tabel tertentu tampaknya sangat lambat, lacak aktivitasnya dari waktu ke waktu, lihat berapa banyak pemindaian berurutan yang didapat vs pemindaian indeks, lihat apakah itu akan menggunakan disk atau memori untuk data.
Jika tabel besar terus sering diautovacuum, lacak tupel hidup hingga mati dari waktu ke waktu, mungkin secara khusus perlu autovacuum untuk di-tweak sehingga dapat selesai lebih cepat, atau bahkan mungkin tabel adalah kandidat untuk dipartisi.
Karena kita dapat melihat kapan data berasal dari disk atau memori, kita dapat membuat rasio memori terhadap disk dari waktu ke waktu, menunjukkan dengan tepat jika rasio menurun sepanjang hari.
Jumlah tabel yang kami bahas melampaui hitter besar, data utama yang berguna untuk mengetahui cara kerja bagian dalam database. Namun ada lebih banyak tabel dalam katalog sistem yang berisi data yang berguna secara situasional. Membaca tabel lain seperti sebelumnya akan membantu memberikan wawasan tentang kesehatan database secara umum.
Untuk informasi lebih lanjut tentang tabel atau tampilan apa pun di Katalog PostgreSQL, kunjungi dokumentasi resmi di sini, serta informasi tentang pengumpul statistik di sini.
