Где хранятся логи postgresql linux

Sysadminium

База знаний системного администратора

Журнал PostgreSQL. Настройка и анализ

В этой статье разберём журнал PostgreSQL, а именно как его настраивать, что в него можно записывать и как его анализировать.

Если помните при запуске PostgreSQL, мы указали файл журнала: pg_ctl start -l /home/postgres/logfile.

В этот журнал PostgreSQL записывает некоторые из своих действий. Настраивая журналирование мы можем задать:

• какие действия заносить в журнал;
• насколько подробно описывать эти действия;
• сколько будут хранится файлы журнала и как переключаться на другие файлы.

Если сейчас заглянуть в журнал и посмотреть последние строчки в которых есть слово FATAL, то можно увидеть следующее:

FATAL: terminating connection due to administrator command – это завершение процесса с помощью функции pg_terminate_backend(pid). Это мы проделывали на прошлом уроке.

За настройку журнала отвечают следующие опции:

• log_destination = можем указать один, или через запятую несколько приёмников:
  • stderr – поток ошибок (в обычном текстовом виде)
  • csvlog – формат CSV (только с коллектором)
  • syslog – писать ошибки в syslog (только для Linux)
  • eventlog – писать ошибки журнал событий Windows (только для Windows)
• logging_collector = (on или off). При включении позволяет собирать дополнительную информацию и никогда не теряет сообщения, в отличие от syslog. При этом запись можно вести в stderr или csvlog. Может стать узким местом, так как после каждого действия записывается журнальная запись и только потом совершается следующее действие.
• log_directory и log_filename – каталог и файл журнала. Следует указывать только если log_destination = stderr.

Что можем записывать в журнал?

В журнал может быть записано много полезной информации. Но по умолчанию почти весь вывод выключен, чтобы снизить нагрузку на диски. Вот что может писаться в журнал сообщений сервера:

• log_min_messages – минимальный уровень логирования. Допустимые значения: DEBUG5 – DEBUG1, INFO, NOTICE, WARNINF, ERROR, LOG, FATAL, PANIC. Каждый из перечисленных уровней включает все идущие после него. По умолчанию используется WARNINF;
• log_min_duration_statement – время в миллисекундах. Если команда выполнялась дольше этого времени, то по ней будет запись в журнале. Если установить равное нулю, то абсолютно все команды буду записаны в журнал;
• log_duration – (on или off) записывать время выполнения команд;
• application_name – (on или off) записывать имя приложения;
• log_checkpoints – (on или off) записывать информацию по контрольным точкам;
• log_(dis)connections – (on или off) записывать подключения к серверу и отключения от него;
• log_lock_waits – (on или off) записывать, если сеанс ожидает блокировку дольше, чем указано в deadlock_timeout;
• log_statement – (none, ddl, mod, all) записывать текст выполняемых команд:
  • none – отключено;
  • ddl – CREATE, ALTER, DROP;
  • mod – dll + INSERT, UPDATE, DELETE, TRUNCATE, COPY;
  • all – все команды (кроме команд с синтаксическими ошибками);
• log_temp_files – использование временных файлов. Если процессу не хватило оперативной памяти то он создаст временный файл на диске и будет его использовать. Если это случается то, например можно увеличить параметр workmem.
• и другое.

Ротация жарналов

Если писать все в 1 файл, то постепенно он вырастит до огромных размеров. Поэтому лучше использовать некоторую схему ротации. Следующими параметрами можно настроить ротацию, если мы используем log_destination=stderr:

• log_filename – может принять не просто имя файла, а маску имени. С помощью специальных символов можно указать текущее время;
• log_rotation_age – задает время переключения на следующий файл в минутах;
• log_rotation_size – задает размер файла, при котором нужно переключиться на следующий файл;
• log_truncate_on_rotation – если включить (on) то вы разрешите серверу перезаписывать уже существующие файлы. Если выключить (off) – то файл не будет перезаписываться, записи будут писаться в конец файла.

Комбинируя все выше перечисленное, можно настроить некоторую схему ротации. Например:

• log_filename = postgres-%H.log / log_rotation_age = 1h – 24 файла в сутки;
• log_filename = postgres-%a.log / log_rotation_age = 1d – 7 файлов в неделю.

Анализ журнала

Анализировать журнал можно средствами операционной системы, например: grep, awk и подобными. А также можно использовать pgBadger – это анализатор лога PostgreSQL, но он требует определённых настроек журнала.

Практика

Настроим журнал, чтобы он захватывал все запросы (log_min_duration_statement=0). Дополнительно в качестве префикса укажем “pid=%p“. Затем заставим сервер перечитать конфигурацию и выполним некоторый запрос (SELECT sum(random()) FROM generate_series(1,1000000)). Далее отключимся от сервера и посмотрим журнал:

Как видите, теперь в логах есть информация обо всех командах и время, которое они выполнялись!

Более подробно про настройку журнала можете почитать здесь.

Источник

Where are PostgreSQL logs files?

Posted by: Mohammed Semari | Published: September 6, 2016| Updated: December 10, 2016

When debugging a problem, it’s always frustrating to get sidetracked hunting down the relevant logs. PostgreSQL users can select any of several different ways to handle database logs, or even choose a combination. But especially for new users, or those getting used to an unfamiliar system, just finding the logs can be difficult. To ease that pain, here’s a key to help dig up the correct logs.

Where are log entries sent?

First, connect to PostgreSQL with psql, pgadmin, or some other client that lets you run SQL queries, and run this:

The log_destination setting tells PostgreSQL where log entries should go. In most cases it will be one of four values, though it can also be a comma-separated list of any of those four values. We’ll discuss each in turn.

SYSLOG

Syslog is a complex beast, and if your logs are going here, you’ll want more than this blog post to help you. Different systems have different syslog daemons, those daemons have different capabilities and require different configurations, and we simply can’t cover them all here. Your syslog may be configured to send PostgreSQL logs anywhere on the system, or even to an external server. For your purposes, though, you’ll need to know what “ident” and “facility” you’re using. These values tag each syslog message coming from PostgreSQL, and allow the syslog daemon to sort out where the message should go. You can find them like this:

Syslog is often useful, in that it allows administrators to collect logs from many applications into one place, to relieve the database server of logging I/O overhead (which may or may not actually help anything), or any number of other interesting rearrangements of log data.

EVENTLOG

For PostgreSQL systems running on Windows, you can send log entries to the Windows event log. You’ll want to tell Windows to expect the log values, and what “event source” they’ll come from. You can find instructions for this operation in the PostgreSQL documentation discussing server setup.

STDERR

This is probably the most common log destination (it’s the default, after all) and can get fairly complicated in itself. Selecting “stderr” instructs PostgreSQL to send log data to the “stderr” (short for “standard error”) output pipe most operating systems give every new process by default. The difficulty is that PostgreSQL or the applications that launch it can then redirect this pipe to all kinds of different places. If you start PostgreSQL manually with no particular redirection in place, log entries will be written to your terminal:

In these logs you’ll see the logs from me starting the database, connecting to it from some other terminal, and issuing the obviously erroneous command “select syntax error”. But there are several ways to redirect this elsewhere. The easiest is with pg_ctl’s -l option, which essentially redirects stderr to a file, in which case the startup looks like this:

Finally, you can also tell PostgreSQL to redirect its stderr output internally, with the logging_collector option (which older versions of PostgreSQL named “redirect_stderr”). This can be on or off, and when on, collects stderr output into a configured log directory.

So if you end see a log_destination set to “stderr”, a good next step is to check logging_collector:

In this system, logging_collector is turned on, which means we have to find out where it’s collecting logs. First, check log_directory. In my case, below, it’s an absolute path, but by default it’s the relative path “pg_log”. This is relative to the PostgreSQL data directory. Log files are named according to a pattern in log_filename. Each of these settings is shown below:

Documentation for each of these options, along with settings governing log rotation, is available here.

If logging_collector is turned off, you can still find the logs using the /proc filesystem, on operating systems equipped with one. First you’ll need to find the process ID of a PostgreSQL process, which is simple enough:

Then, check /proc/YOUR_PID_HERE/fd/2, which is a symlink to the log destination:

CSVLOG

The “csvlog” mode creates logs in CSV format, designed to be easily machine-readable. In fact, this section of the PostgreSQL documentation even provides a handy table definition if you want to slurp the logs into your database. CSV logs are produced in a fixed format the administrator cannot change, but it includes fields for everything available in the other log formats. For these to work, you need to have logging_collector turned on; without logging_collector, the logs simply won’t show up anywhere. But when configured correctly, PostgreSQL will create CSV format logs in the log_directory, with file names mostly following the log_filename pattern. Here’s my example database, with log_destination set to “stderr, csvlog” and logging_collector turned on, just after I start the database and issue one query:

Источник

pg_log, pg_xlog, pg_clog: с чем их едят

— Я тут типа удалил несколько Гб лог-файлов из каталога pg_xlog, чтобы освободить место на диске. Теперь моя база данных не взлетает.

— Ой-вей! Кхе-кхе… А когда говорите в последний раз резервную копию делали?

Именно в такой форме несколько раз взывали заказчики и пользователи о помощи на нашем IRC-канале. Учитывая легкость повторения этой ошибки, я решил выложить некоторую информацию о системных каталогах PostgreSQL.

Существует три директории в каталоге $PGDATA при его создании, которые имеют вид «pg_*log».

pg_log

$PGDATA/pg_log является по умолчанию местом, где хранятся журналы деятельности. Они включают в себя сообщения об ошибках, записи о запросах, и сообщения во время старта\выключения СУБД. Именно здесь следует искать информацию в случае, если PostgreSQL не запускается. Многие дистрибутивы Linux грешат тем, что могут переместить этот каталог куда-нибудь в /var/log/postgresql.

Вы можете свободно удалять, переименовывать, сжимать и перемещать файлы из pg_log без опаски, при условии что пользователь postgres имеет право на запись в каталог. Если pg_log раздувается за счет больших файлов, то вероятно, вам следует урезать список журналируемых вещей, изменив настройки в postgresql.conf.

pg_xlog

$PGDATA/pg_xlog — это место, где PostgreSQL хранит журнал транзакций. Этот набор бинарных файлов, с названиями вида ‘00000001000000000000008E’, которые содержат образы данных последних транзакций. Эти журналы также используются при бинарной репликации.

Если репликация, архивирование или PITR (Point-In-Time-Recovery) отказывают, этот каталог рискует стать раздутым гигабайтами логов, которые сервер пишет на случай, если архивирование возобновится. Это может стать причиной переполнения дискового пространства.

В отличие от pg_log, вы не можете свободно удалять, перемещать или сжимать файлы в этом каталоге. Удаление файлов из pg_xlog может привести к невосстановимому повреждению базы данных.

Если вы окажетесь в ситуации, когда у вас есть 100 ГБ файлов в pg_xlog и база данных не запускается, и вы уже отключили архивирование/репликацию, и уже попытались очистить дисковое пространство любым другим способом, то, пожалуйста, сделайте два шага:

1. Переместите файлы из pg_xlog на диск для резервного копирования или общий сетевой диск, но ни в коем случае не удаляйте их.
2. Скопируйте обратно в pg_xlog только несколько наиболее старых файлов. Этого достаточно, чтобы PostgreSQL стартовал в штатном режиме.

pg_clog

$PGDATA/pg_clog содержит журналы метаданных транзакций. Этот журнал говорит серверу, какие транзакции завершены, а какие нет. Этот каталог мал и нету каких-либо предпосылок для его вздувания. Скорее всего вам никогда не придется его трогать.

Но если вы когда-нибудь удалите файлы из pg_clog, вы можете смело удалить и весь каталог базы данных. Не существует способа восстановить базу данных без этих журналов.

Стоит отметить, что если вы предпочитаете создавать резервные копии файлов в каталоге $PGDATA, вам следует убедиться, что каталоги pg_clog и pg_xlog также архивируются. В противном случае вы можете обнаружить, что резервная копия бесполезна.

Источник

PostgreSQL

Обучение PostgreSQL. Полный курс по работе с базой данных PostgreSQL!

Курс включает в себя все инструменты: управление доступом, резервное копирование, репликация, журналирование, работа со статистикой, способы масштабирование, а также работа PostgreSQL в облаках AWS, GCP, Azure и в Kubernetes. Проверь свои знания — пройди тестирование

PostgreSQL (произносится «Постгре-Эс-Кю-Эль», коротко называется «Постгрес») — свободная объектно-реляционная система управления базами данных (СУБД система управления базами данных). Использует порт 5432/tcp/udp. PostgreSQL использует только один механизм хранения данных под названием Postgres storage system (система хранения Postgres), в котором транзакции и внешние ключи полностью функциональны, в отличии от MySQL, в котором InnoDB и BDB являются единственными типами таблиц, которые поддерживают транзакции.

По умолчанию PostgreSQL настроен так, что каждый локальный пользователь может подсоединиться к базе совпадающей по названию с регистрационным именем клиента, при условии что такая база данных уже создана.

MVCC — одна из ключевых технологий доступа к данным, которая используется в PostgreSQL. Она позволяет осуществлять параллельное чтение и изменение записей (tuples) одних и тех же таблиц без блокировки этих таблиц. Чтобы иметь такую возможность, данные из таблицы сразу не удаляются, а лишь помечаются как удаленные. Изменение записей осуществляется путем маркировки этих записей как удаленных, и созданием новых записей с измененными полями. Таким образом, история изменений одной записи сохраняется в базе данных и доступна для чтения другими транзакциями. Этот способ хранения записей позволяет параллельным процессам иметь неблокирующий доступ к записям, которые были удалены или изменены в параллельных незакрытых транзакциях. Техника, используемая в этом подходе, относительно простая. У каждой записи в таблицы есть системные скрытые поля xmin, xmax.

Перед началом выборки данных PostgreSQL сохраняет снапшот текущего состояния БД. На основании данных снапшота, полей xmin, xmax осуществляется фильтрация записей.

pg_hba.conf идентификация пользователей

pg_hba.conf — настройка политики доступа к базам данных и идентификации пользователей сервера PostgreSQL.

В этом файле описываются клиентские компьютеры сети, с которых разрешен доступ к SQL серверу PostgreSQL, а также методы идентификации клиентов. Этот файл может содержать два вида записей:

Примеры записей pg_hba.conf:

Кодировка БД PostgreSQL и locale

PostgreSQL поддерживает только общую для всех баз кластера кодировку, которая должна совпадать с локальной кодировкой (Настройка переменных локализации в Linux), иначе не будут работать строковые функции сортировки, upper/lower и т.п. Локаль общая для всех процессов сервера — соответственно он не может создать две базы в разных кодировках — кодировка всегда одна для всего сервера и всех его БД.

Посмотреть кодировку сервера (show server_encoding) и клиента(show client_encoding):

Т.е. создать базу в другой кодировке можно, но тогда в ней будут неправильно работать функции обработки строк и сортировка строк.

Указывать список кодировок нужно не для createdb (create database), а для подключения клиента к серверу (client_encoding), если кодировка символов которую ожидает программа-клиент не совпадает с её (программы-клиента) текущей системной локалью, с которой она была запущена.

Клиенты администрирования PostgreSQL

psql — PostgreSQL interactive terminal.

В директории /usr/share/doc/postgresql* можно найти дополнительную информацию по запуску.

Посмотреть и удалить активные запросы

Если запрос запущен из интерфейса pgsql, то завершение работы сервера не поможет — запрос все равно продолжит свое выполнение, необходимо вызывать функцию pg_cancel_backend.

SELECT запросы можно снимать из ОС командой kill

Транзакции в PostgreSQL

В PostgreSQL Транзакция — это список команд SQL, которые находятся внутри блока, начинающегося командой BEGIN и заканчивающегося командой COMMIT.

PostgreSQL фактически считает каждый оператор SQL запущенным в транзакции. Если вы не указываете команду BEGIN, то каждый отдельный оператор имеет неявную команду BEGIN перед оператором и (при успешной отработке оператора) команду COMMIT после оператора. Группа операторов заключаемая в блок между BEGIN и COMMIT иногда называется транзакционным блоком.

Пример запуска транзакции из файла delprices.sql, которая удаляет в БД test777 из таблиц prices и ratesheets строки с >

Выполним транзакцию для test777:

Мониторинг, логи, размер БД PostgreSQL

Лог файлы

Лог файлы PostgreSQL находятся в директории pg_log, для Fedora полный путь /var/lib/pgsql/data/pg_log. Детализация лог файлов настраивается в postgresql.conf.

Мониторинг

Текущую активность базы данных легко оценить с помощью команды ps, для вывода в реальном времени (с задержкой 1 секунда) можно использовать утилиту Команда watch с практическим примерами:

Так как для каждого клиента создаётся своя копия процесса postmaster, то это позволяет подсчитать число активных клиентов. Статусная строка даёт информацию о состоянии клиента. Фразы writer process, stats buffer process и stats collector process соответствуют системным процессам, запущенным самим PostgreSQL при старте. Пользовательские процессы имеют статусную строку вида:

«пользователь», «база» и «хост» соответствуют имени пользователя «пользователь» подсоединявшегося к базе «база» с компьютера «хост». «статус» может принимать следующие параметры:

Views сборщик статистики

Представления (Views) сборщика статистики.

Если в PostgreSql postgresql.conf разрешён сбор статистики (logging_collector = on), то информация об активности базы данных собирается в специальных системных таблицах.

Информация собранная «статистическим сборником» может оказаться полезной для оценки эффективности базы данных и запросов. Из этих представлений можно узнать, например

Стандартные Statistics Views. Вывести все представления каталога

Вывести соотношение hit/read. При выполнении запроса PostgreSQL сначала смотрит, есть ли нужные в запросе данные в разделяемой памяти (shared buffers). Если они найдены, засчитывается hit, если нет — делается сравнительно медленный системный вызов fread для поднятия данных с диска или из дискового кеша операционной системы и засчитывается read. В среднем, верно правило: чем больше отношение hit/read, тем лучше настроен PostgreSQL, так как он очень мало читает с диска, в основном извлекая данные из разделяемой памяти. Для большинства не очень больших баз это отношение должно лежать в пределах 5000-10000. Не стремитесь, однако, искусственно завысить настройку shared_buffers, которая прямо определяет hit/read: слишком большие размеры разделяемой памяти ведут к потере производительности в базах с интенсивной записью. Также стоит помнить, что fread может быть довольно быстрым, если данные находятся в дисковом кеше ОС.

Количество модификаций, произошедших в таблице. Список по таблицам: какое количество записей в них было добавлено, изменено и удалено с момента последнего сброса статистики. Администратор БД должен представлять, какие таблицы являются самыми нагруженными в текущей базе данных, а также каково соотношение между различными типами модифицирующих запросов к ним.

Статистика по индексам. Список по индексам: сколько записей из индекса были использованы в запросах по этому индексу; сколько рядов при этом получилось достать из родительской таблицы; разность этих двух чисел. Суть данной статистики проста: если у вас большая разница read-ов и fetch-ей, значит индекс устарел и ссылается на уже несуществующие данные, т.е. не всякий просмотр индекса и чтение из него соответствующего указателя на данные из таблицы (read) вызывает чтение самих данных из таблицы (fetch). В этом случае необходимо перестроить данный индекс, чтобы он соответствовал реальным данным в таблице.

Уровни блокировок таблиц

Команда LOCK TABLE предназначена для блокировки таблиц на время транзакции. Блокировкой называется временное ограничение доступа к таблице (в зависимости от выбранного режима). Сеанс, заблокировавший таблицу, пользуется нормальным доступом; последствия блокировки распространяются только на других пользователей, пытающихся получить доступ к заблокированной таблице.

Некоторые команды SQL автоматически устанавливают блокировку для выполнения своих функций; в таких случаях PostgreSQL всегда выбирает минимально необходимый уровень блокировки. После завершения транзакции блокировка немедленно снимается.

Команда LOCK TABLE без параметра устанавливает максимально жесткий режим блокировки (ACCESS EXCLUSIVE). Чтобы ограничения были менее жесткими, следует явно задать нужный режим.

Ситуация взаимной блокировки (deadlock) возникает в там случае, когда каждая из двух транзакций ожидает снятия блокировки другой транзакцией. Хотя PostgreSQL распознает взаимные блокировки и завершает их командой ROLLBACK, это все равно причиняет определенные неудобства. Приложения не должны сталкиваться с проблемой взаимных блокировок, поэтому проектируйте их так, чтобы объекты всегда блокировались в одинаковом порядке.

Automatic Vacuuming

Автоматическая сборка мусора (Automatic Vacuuming).

Синтаксис VACUUM:

Синтаксис ANALYZE:

Кроме сборки мусора (VACUUM) производится ещё и анализ (ANALYZE). Периодическое выполнение команды ANALYZE необходимо для нормального функционирования планировщика. Собранная с помощью этой команды статистика позволяет значительно ускорить выполнение SQL- запросов. То есть, если не хочется настраивать автоматическую сборку мусора, то в любом случае её придётся делать только теперь в ручную. Процесс обычной сборки мусора в PostgreSQL (VACUUM без приставки FULL) не блокирует таблиц и может выполняться в фоне, не мешая выполнению запросов. Регулярное исполнение команд VACUUM и ANALYZE обязательно. Это необходимо по той причине, что иначе не получится заново использовать дисковое пространство, которое занимают ранее удалённые или изменённые строки и не удастся обновить статистику для планировщика запросов. И то и другое отрицательно сказывается на эффективности использования ресурсов и производительности запросов. Начиная с версии PostgreSQL 8.1 сервер может самостоятельно автоматически запускать ещё один системный процесс, который, соответственно, так и называется autovacuum daemon. Все настройки для этого процесса хранятся в PostgreSql postgresql.conf. К значениям этих параметров следует отнестись крайне внимательно. Если по каким-то причинам демон было решено не запускать, то в любом случае необходимо производить сборку мусора и набор статистики в ручную.

Основным средством физического и аналитического сопровождения баз данных в PostgreSQL является команда SQL VACUUM и ее аналог — сценарий vacuumdb. Оба средства выполняют две общие функции:

При наличии необязательного ключевого слова ANALYZE PostgreSQL анализирует структуру данных во всех полях всех таблиц (или только заданной таблицы, если она указана), после чего эта информация используется оптимизатором запросов для более эффективного планирования. Ключевое слово ANALYZE также позволяет ограничить анализ отдельными полями.

Практика показала, что без более-менее регулярных запусков vacuum full analyze производительность системы постепенно падает, причем чем дальше, тем больше. Разница между vacuum и vacuum full заключается в том, что full физически переписывает на диске всю таблицу таким образом, чтобы в ней не оставалось «дырок» от удаленных или обновленных записей. Но его недостаток в том, что во время работы таблица полностью блокируется(включая и select запросы), что может привести к проблемам на популярном сервере — начнет скапливаться очередь запросов, ожидающих доступа к базе, каждый запрос требует памяти, память кончается, начинается запись в Как посмотреть информацию о swap?, из-за отсутствия памяти сам vacuum тоже начинает использовать swap и все начинает работать очень-очень медленно. Простой VACUUM (Без FULL) просто восстанавливает пространство и делает его доступным для повторного использования. Эта форма команды умеет работать параллельно с обычными чтение и запись таблицы, без монопольной блокировки.

Чтобы определить необходимость использования индекса для какой-либо таблицы, PostgreSQL должен иметь статистику по этой таблице. Эта статистика собирается при использовании VACUUM ANALYZE или просто ANALYZE. Используя статистику, оптимизатор узнает о том как много строк в таблице и если он должен использовать индексы, то он может принимать лучшие решения. Статистика также влияет на определение оптимального порядка соединений таблиц и метода соединения. При изменении содержимого таблицы должен периодически выполнятся сбор статистики.

Получение id добавленной записи в PostgeSQL

lcr_id — колонка автоинкрементная (lcr_id | integer | not null default nextval(‘df_lcr_list_lcr_id_seq’::regclass)). Запрос возвращает значение колонки lcr_id для вставленной записи, в этом случае id записи.

Системные таблицы pg_

Системные таблицы(System Catalogs) PostgreSQL начинаются с префикса pg_.

№	Имя таблицы	Назначение таблицы
1	pg_aggregate	aggregate functions
2	pg_am	index access methods
3	pg_amop	access method operators
4	pg_amproc	access method support procedures
5	pg_attrdef	column default values
6	pg_attribute	table columns («attributes»)
7	pg_authid	authorization identifiers (roles)
8	pg_auth_members	authorization identifier membership relationships
9	pg_cast	casts (data type conversions)
10	pg_class PostgreSQL System Catalogs	tables, indexes, sequences, views («relations»)
11	pg_constraint	check constraints, unique constraints, primary key constraints, foreign key constraints
12	pg_conversion	encoding conversion information
13	pg_database	databases within this database cluster	Хранятся имена доступных баз данных
14	pg_depend	dependencies between database objects
15	pg_description	descriptions or comments on database objects	В таблице хранятся описания объектов, для которых была применена функция COMMENT (расширение PostgreSQL). Например COMMENT ON TABLE mytable IS ‘Эта строка будет сохранена в системной таблице pg_description.’;
16	pg_enum	enum label and value definitions
17	pg_foreign_data_wrapper	foreign-data wrapper definitions
18	pg_foreign_server	foreign server definitions
19	pg_index	additional index information
20	pg_inherits	table inheritance hierarchy
21	pg_language	languages for writing functions
22	pg_largeobject	large objects
23	PostgreSQL pg_listener	asynchronous notification support	Используется механизмом LISTEN/NOTIFY. pg_listener существует в версиях PostgreSQL меньше 9.
24	pg_namespace	schemas
25	pg_opclass	access method operator classes
26	pg_operator	operators
27	pg_opfamily	access method operator families
28	pg_pltemplate	template data for procedural languages
29	pg_proc	functions and procedures
30	pg_rewrite	query rewrite rules
31	pg_shdepend	dependencies on shared objects
32	pg_shdescription	comments on shared objects
33	pg_statistic	planner statistics
34	pg_tablespace	tablespaces within this database cluster
35	pg_trigger	triggers	Триггеры хранятся в системной таблице pg_trigger, что позволяет получить информацию о существующих триггерах на программном уровне.
36	pg_ts_config	text search configurations
37	pg_ts_config_map	text search configurations’ token mappings
38	pg_ts_dict	text search dictionaries
39	pg_ts_parser	text search parsers
40	pg_ts_template	text search templates
41	pg_type	data types
42	pg_user_mapping	mappings of users to foreign servers
Представления (View)	Назначение
43	pg_cursors	open cursors
44	pg_group	groups of database users
45	pg_indexes	indexes
46	pg_locks блокировки в PostgreSQL	currently held locks	Содержит информацию о блокировках. Уровни блокировок таблиц.
47	pg_prepared_statements	prepared statements
48	pg_prepared_xacts	prepared transactions
49	pg_roles	database roles
50	pg_rules	rules
51	pg_settings	parameter settings
52	pg_shadow	database users	Существует для обратной совместимости, она имитирует каталог, который существовал в PostgreSQL до версии 8.1.
53	pg_stats	planner statistics
54	pg_tables	tables
55	pg_timezone_abbrevs	time zone abbreviations
56	pg_timezone_names	time zone names
57	pg_user	database users	Информативный характер о пользователях, пароль содержится в таблице pg_shadow
58	pg_user_mappings	user mappings
59	pg_views	views

Partitioning (Партицирование)

Partitioning (партицирование, секционирование).

Ссылки

Обучение PostgreSQL. Полный курс по работе с базой данных PostgreSQL!

Курс включает в себя все инструменты: управление доступом, резервное копирование, репликация, журналирование, работа со статистикой, способы масштабирование, а также работа PostgreSQL в облаках AWS, GCP, Azure и в Kubernetes. Проверь свои знания — пройди тестирование

Источник