Современный инстанс PostgreSQL пишет подробные и детальные логи практически обо всём, что происходит с базой и запросами. Логи PostgreSQL — это не только основной инструмент для поиска и отладки критических ошибок, но и важный инструмент мониторинга производительности приложений.
В этой статье мы разберём настройку логирования в PostgreSQL — начиная с основ: что логировать, как настраивать нужное вам логирование и в конце посмотрим, как эти логи помогают реально ускорять работу базы. Документация PostgreSQL по логам отлично написана, поэтому обращайтесь к ней за самыми актуальными и полными конфигурациями. Эта статья дополняет официальные рекомендации практическими советами и настройками.
Мы обсудим:
Настройку уровней логирования, логирование SQL, ротацию логов
Логирование для мониторинга производительности
Извлечение и парсинг логов для получения полезной информации
Примечание о WAL: в этой статье речь идёт только о сообщениях сервера и логах ошибок, а не о журнале предзаписи транзакций (Write Ahead Log, WAL). Хотя WAL тоже является журналом, его назначение — фиксировать все изменения данных и схемы для резервного копирования, восстановления после сбоев и потоковой репликации.
Инициализация логирования в PostgreSQL
По умолчанию PostgreSQL отправляет логи только в терминал. Чтобы включить запись логов в файлы, нужно активировать сборщик логов (logging collector).
logging_collector = onВ каком формате нужны логи?
Формат сообщений задаётся параметром log_destination, который может быть установлен в одно или несколько значений: stderr, csvlog, jsonlog и syslog. По умолчанию используется stderr. При указании нескольких вариантов используйте запятую для разделения:
-- настройка нескольких мест назначения логов
log_destination = 'stderr,jsonlog' Если logging_collector = 'on', то вывод в stderr, csvlog и jsonlog будет записываться в файлы в каталоге, указанном в log_directory. Для форматов csv и json требуется включённый logging collector.
Есть множество причин хранить логи в нескольких форматах. Во многих хостинговых и управляемых системах логи доступны в разных форматах для использования различными инструментами. В Crunchy Bridge, например, у нас живые логи и «log tail» в CLI через syslog. Для внутренних логов мы часто используем jsonlog. На серверах syslog обычно используется для отправки логов на внешний хост.
Какой уровень логирования выбрать?
Сообщения в логах PostgreSQL имеют уровень серьёзности (severity). Они упорядочены от менее критичных к наиболее критичным:
DEBUG1–5 — отладочные сообщения разной детализации (обычно используются разработчиками и для диагностики).
INFO — информационные сообщения, не влияющие на работу (например, уведомления статистики, служебные детали).
NOTICE — полезные уведомления, не являющиеся ошибкой (например, DROP TABLE IF EXISTS при отсутствии таблицы).
WARNING — потенциальные проблемы: использование устаревших функций, подозрительные данные.
ERROR — ошибка в запросе, прерывает только текущую операцию, но не завершает сессию.
LOG — важные сообщения сервера: контрольные точки (checkpoints), autovacuum, запуск/остановка сервера.
FATAL — ошибка, приводящая к завершению сессии.
PANIC — критическая ошибка, сервер аварийно завершается и переходит в восстановление.
Примеры сообщений лога:
-- сбой фонового процесса
ERROR: background worker "logical replication launcher" crashed
-- ошибка дискового ввода-вывода
ERROR: could not fsync file "pg_wal/0000000100000000000000A3": Input/output error
-- нехватка места на диске для временных файлов
ERROR: could not create temporary file: No space left on device
-- предупреждение от autovacuum
WARNING: relation "public.large_table" contains more than "autovacuum_vacuum_threshold" dead tuplesПараметр log_min_messages определяет, начиная с какого уровня сообщения будут попадать в лог.
По умолчанию используется значение warning, то есть логируются все сообщения уровня WARNING и выше (ERROR, LOG, FATAL, PANIC).
Для отладки можно временно снижать уровень, например до info или даже debug5, чтобы видеть больше служебных сообщений. В боевых системах обычно оставляют warning или error.
Пример:
log_min_messages = 'warning'Логирование SQL в PostgreSQL
Помимо выбора уровня серьёзности, можно настроить логирование SQL-запросов с помощью параметра log_statement. Возможные значения:
none — ничего не логировать. По умолчанию SQL-запросы не пишутся в лог, но предупреждения и ошибки будут отображаться в зависимости от настройки log_min_messages.
ddl — логировать только изменения структуры данных (DDL): изменения таблиц, колонок и индексов.
mod — логировать изменения данных, включая все DDL, а также операции INSERT, UPDATE и DELETE.
all — логировать каждый SQL-запрос, включая все DDL (обычно не включают в продакшене).
Для продакшена чаще всего достаточно логировать только DDL.
log_statement = 'ddl' Операторы с синтаксическими ошибками или ошибки на этапе парсинга/планирования не попадают под действие параметра log_statement. Для них используется настройка log_min_error_statement, которую следует выставить на ERROR или ниже, чтобы такие ошибки логировались.
log_min_error_statement = 'error' Ошибки SQL в логах выглядят примерно так. Если есть подсказка, то рядом появится строка HINT. Если включено логирование самого запроса (log_min_error_statement = 'error'), то он будет отображаться последним:
2025-05-09 14:02:37 UTC [28561] ERROR: operator does not exist: integer == integer at character 33
2025-05-09 14:02:37 UTC [28561] HINT: Perhaps you meant to use the standard operator "=".
2025-05-09 14:02:37 UTC [28561] STATEMENT: SELECT * FROM users WHERE id == 42; Логирование подготовленных выражений и чувствительных данных
Одна из распространённых задач — исключить из логов чувствительные данные, такие как номера банковских карт или персональные данные (PII). Параметры log_parameter_max_length и log_parameter_max_length_on_error позволяют ограничить длину записываемых значений параметров, подставляемых в подготовленные выражения, соответственно для обычных логов запросов и для логов ошибок. Эти настройки применяются как к именованным подготовленным выражениям (PREPARE / EXECUTE), так и к «безымянным» подготовленным выражениям, которые используют драйверы БД через протокол extended query.
По умолчанию стоит -1 — это значит, что логируются все параметры полностью. Чтобы отключить логирование параметров, установите 0:
log_parameter_max_length = 0
log_parameter_max_length_on_error = 0Если ограничение требуется только для отдельных запросов или транзакций, параметры можно задать «на лету» через SET SESSION и SET LOCAL. Также их можно устанавливать глобально: для всех запросов конкретного пользователя (ALTER ROLE), конкретной базы (ALTER DATABASE) или даже для определённого пользователя в конкретной базе.
Примеры:
-- для всей сессии
SET SESSION log_parameter_max_length = 0;
SET SESSION log_parameter_max_length_on_error = 0;
-- для транзакции
BEGIN;
SET LOCAL log_parameter_max_length = 0;
SET LOCAL log_parameter_max_length_on_error = 0;
...
COMMIT;
-- для всех запросов пользователя bob
ALTER ROLE bob SET log_parameter_max_length = 0;
ALTER ROLE bob SET log_parameter_max_length_on_error = 0;
-- для всей базы pii_db
ALTER DATABASE pii_db SET log_parameter_max_length = 0;
ALTER DATABASE pii_db SET log_parameter_max_length_on_error = 0;
-- для всех запросов bob в базе pii_db
ALTER ROLE bob IN DATABASE pii_db SET log_parameter_max_length = 0;
ALTER ROLE bob IN DATABASE pii_db SET log_parameter_max_length_on_error = 0; Как форматировать записи в логах
По умолчанию записи PostgreSQL выглядят так:
2025-05-19 13:49:04.908 EDT [3108283] ERROR: column "asdfklasdf" does not exist at character 8 Часть с временной меткой и идентификатором процесса формируется параметром log_line_prefix:
log_line_prefix = '%m [%p] ' Часто советуют задать более информативный префикс, чтобы сразу видеть, от имени какого пользователя и в какой базе сработало сообщение:
log_line_prefix = '%m [%p]%q %u@%d ' Важно оставлять идентификатор процесса (%p), он здорово помогает при отладке: можно быстро найти и остановить конкретный процесс. %u добавит имя пользователя, %d — имя базы данных. Особенно удобно, если в инстансе несколько баз.
Полный список доступных printf-подобных спецификаторов есть в документации к log_line_prefix.
Параметр log_error_verbosity отвечает за степень подробности сообщений об ошибках:
terse— краткий формат с кодом состояния SQL и сокращёнными сообщениями,default— ошибки и подсказки (hint) включены,verbose— добавляет дополнительный контекст, включая источники и имена функций (не рекомендуется для продакшена, но удобно в разработке).
Пример настройки:
log_error_verbosity = 'default' Аудиторское логирование
Кроме обычных логов, можно вести аудит действий пользователей с помощью расширения PGAudit. PGAudit не входит в ядро PostgreSQL, однако пакеты для него есть в репозиториях всех основных дистрибутивов ОС.
Использование расширения PGAudit требует, чтобы параметр pgaudit был указан в shared_preload_libraries, расширение было создано в каждой базе данных, где нужен аудит, а параметр pgaudit.log был установлен в значение, отличное от none.
-- добавить в список предзагружаемых библиотек
shared_preload_libraries = 'pgaudit'
-- создать расширение
CREATE EXTENSION pgaudit;
-- включить pgaudit.log
pgaudit.log = ddl Аудиторские логи фиксируют более детальные данные: кто выполнил действие, когда это произошло, какие именно изменения были внесены. Это позволяет отслеживать конкретные действия пользователей, включая INSERT, UPDATE, DELETE и административные команды. Возможные значения для pgaudit.log: read, write, role, ddl, misc.
ALTER ROLE audited_user SET pgaudit.log = 'read, write, ddl'; Пример записи аудиторского лога (формат CSV):
2025-05-09 12:34:56.789 UTC [12345] myuser@mydb LOG: AUDIT: SESSION,1,SELECT,pg_catalog.pg_stat_activity,SELECT * FROM pg_stat_activity; Да, обычные и аудиторские логи частично пересекаются — так и задумано. pgAudit предоставляет более детализированное логирование (включая данные о сессии, ролях и изменениях) в дополнение к встроенному логированию PostgreSQL. Если вам нужно фиксировать только DDL-операции и дополнительные возможности аудита не нужны, то достаточно параметра log_statement = 'ddl'.
В Crunchy Bridge мы ведём аудит всего, кроме роли приложения. Таким образом, по умолчанию аудит включён для вашей основной роли PostgreSQL и всех создаваемых пользовательских ролей.
Имена и расположение файлов логов
Параметр log_filename задаёт формат имён файлов журналов с помощью escape-шаблонов strftime. По умолчанию имя файла включает «postgresql» и временную метку.
log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' Обычно детализация до часов, минут и секунд избыточна, поэтому часто используют более простой формат:
log_filename = 'postgresql-%Y-%m-%d'Файлы stderr будут иметь расширение .log, файлы csvlog — .csv, а jsonlog — .json.
Файлы, записываемые PostgreSQL в формате stderr, csvlog и jsonlog, размещаются в каталоге, указанном в log_directory. Это может быть как абсолютный путь, так и путь, относительный к data_directory. Расположение файлов, пишущихся в syslog, зависит от конфигурации syslog на системе.
Примеры:
-- где на хосте находится каталог данных
SHOW data_directory;
-- где находится каталог логов
SHOW log_directory;
-- как выглядят имена файлов логов
SHOW log_filename;
-- точное расположение текущего файла лога
SELECT pg_current_logfile(); Ротация логов
Теперь у нас есть настроенные логи… Но если не настроить их ротацию, то диск очень быстро заполнится.
Пример настройки ротации раз в сутки:
log_rotation_age = '1d' Пример настройки ротации по размеру: если файл превысил 10 МБ раньше, чем прошло 24 часа:
log_rotation_size = '10MB' Если формат log_filename приведёт к повторному использованию одного и того же имени файла (например, postgresql-Mon.log будет использоваться каждый понедельник), параметр log_truncate_on_rotation заставит файл логов обнуляться перед каждым повторным использованием. Если log_truncate_on_rotation не включён, то данные будут дописываться в существующий файл, а не затираться.
log_truncate_on_rotation = 'on' Если используется формат имени файла, исключающий повторное использование (например, postgresql-%Y-%m-%d.log), рекомендуется задействовать внешний инструмент ротации логов, такой как Linux logrotate. Так можно удалять старые логи после архивации, чтобы не тратить лишнее место.
Отладка с помощью логов
Теперь, когда базовое логирование настроено, его можно использовать для диагностики проблем в системе. Обычно работа с логами выглядит так:
Кто-то замечает проблему: база тормозит, упала или сработали алерты.
Смотрим метрики: скачок CPU? I/O? Чем точнее определим время — тем проще искать.
Поднимаем логи за этот интервал, ищем ошибки, блокировки или странные сообщения.
Если виноват конкретный процесс — находим его PID. Запрос/блокировка? Пробуем прибить. Тяжёлая джоба душит систему? Разбираем последствия.
Логируем узкие места
Итак, если вы всё ещё читаете, значит у нас уже есть логи, мы понимаем их структуру и назначение, и можем использовать их для поиска критических ошибок. Но в идеале ошибки случаются редко — куда важнее ускорять запросы. Для этого и пригодится правильное логирование.
Логирование долгих запросов
Если вы хотите ловить в логах запросы, которые выполняются дольше заданного времени, используйте параметр log_min_duration_statement. Это порог логирования «медленных запросов» в PostgreSQL, который особенно полезен для отладки длительных операций.
Начав работать над оптимизацией производительности, самое полезное — логировать самые долгие запросы, чтобы понять, что тормозит.
log_min_duration_statement = '1s' Пример записи в лог для запроса, выполнявшегося более 1 секунды:
LOG: duration: 2001.342 ms statement: SELECT count(*) from orders; Логирование блокировок и ожидания блокировок
Вы можете включить логирование ситуаций, когда запрос ждёт получения блокировки, с помощью параметра log_lock_waits. Такие записи сразу показывают, где процессы упираются друг в друга.
Включение этой опции практически не создаёт накладных расходов и абсолютно безопасно для рабочих баз данных. В кластерах Crunchy Bridge параметр включён по умолчанию:
log_lock_waits = 'on' Порог логирования ожиданий задаётся параметром deadlock_timeout. Например, если deadlock_timeout = '1s', то любой запрос, который ждёт блокировку 1 секунду и дольше, попадёт в лог.
Пример записи об ожидании блокировки:
2024-05-16 14:45:12.345 UTC [45678] user@database LOG: process 45678 still waiting for ShareLock on transaction 123456 after 1000.001 ms
2024-05-16 14:45:12.345 UTC [45678] user@database DETAIL: Process holding the lock: 12345. Wait queue: 45678, 45670.
2024-05-16 14:45:12.345 UTC [45678] user@database STATEMENT: UPDATE orders SET status = 'shipped' WHERE id = 42;Из этой записи видно:
PID процесса, для которого зафиксировано ожидание блокировки;
PID процесса, удерживающего блокировку;
список PID всех процессов, ожидающих блокировку, в порядке их запросов;
сам запрос, которому требуется блокировка.
Логирование временных файлов
Эффективное использование памяти PostgreSQL — ключ к быстрой и отзывчивой работе базы данных. Если запросы вынуждены выполнять сортировку или хеширование на диске вместо работы в памяти, это сигнал к оптимизации: возможно, нужно увеличить work_mem, добавить ресурсы или переписать запрос.
Параметр log_temp_files позволяет логировать создание временных файлов. По умолчанию он выключен (-1). Если задать 0, PostgreSQL будет записывать в лог все операции создания временных файлов, что обычно избыточно.
Значение log_temp_files не обязательно должно совпадать с work_mem: один запрос может содержать несколько операций сортировки или хеша, и итоговый временный файл может быть как немного больше лимита, так и существенно его превышать. Поэтому обычно задают фиксированный порог (например, 1–10 МБ), чтобы фиксировать действительно тяжёлые запросы.
Если операция помещается в work_mem, временные файлы не создаются и логирование не требуется. Если лимит превышен, PostgreSQL создаёт временный файл соответствующего размера, и это помогает увидеть, какие запросы выходят за рамки выделенной памяти.
Пример настройки:
-- логировать временные файлы больше 4 МБ
ALTER SYSTEM SET log_temp_files = '4096';Пример записи в логе:
2024-05-16 14:23:05.123 UTC [12345] user@database LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp1234.0", size 245760
2024-05-16 14:23:05.123 UTC [12345] user@database DETAIL: Sort operation used temporary file because work_mem was exceededЛогирование запросов с помощью auto_explain
auto_explain — это расширение Postgres, которое автоматически записывает планы выполнения запросов (EXPLAIN) в лог. Оно полезно для отладки и оптимизации производительности. Расширение auto_explain есть в PostgreSQL, но включается вручную.
-- добавить в список предзагружаемых библиотек
shared_preload_libraries = 'auto_explain'
-- после перезапуска создать расширение
CREATE EXTENSION IF NOT EXISTS auto_explain;
-- после этого перезапустить PostgreSQL Можно настроить auto_explain так, чтобы в лог попадали планы запросов определённой продолжительности:
-- логировать планы для запросов, выполнявшихся дольше 1000 мс
auto_explain.log_min_duration = '1000ms'; У расширения есть и другие параметры, например, для отображения использования буферов. Подробности — в документации по auto_explain. Стоит учитывать, что auto_explain генерирует большое количество логов, поэтому использовать его нужно осторожно. Для очень тяжёлых запросов или запросов по секционированным таблицам планы могут быть огромными. Альтернативой постоянному включению auto_explain может быть его активация только для отдельной сессии.
Пример лога auto_explain:
LOG: duration: 1008.035 ms plan:
May 17 02:42:06 z7j4asvir5dufokh5hpzoy postgres[43712]: [29-2]
Query Text: select count(*) from page_hits limit 1000; Логирование autovacuum
Логировать autovacuum или нет — решает параметр log_autovacuum_min_duration. Начиная с PG15, он по умолчанию равен 10 минутам, а в предыдущих версиях был отключён (значение -1). Поскольку записи autovacuum содержат ту же информацию, что и VACUUM VERBOSE, многие администраторы снижают порог до одной-двух секунд для получения подробной информации о работе демона autovacuum, а иногда ставят 0, чтобы логировались все его действия.
log_autovacuum_min_duration = '1s' Пример записи о работе autovacuum (начиная с PostgreSQL 15):
[3506673][autovacuum worker][501/2614][0] LOG: automatic vacuum of table "testdb.public.pgbench_accounts": index scans: 1
pages: 0 removed, 327869 remain, 81969 scanned (25.00% of total)
tuples: 0 removed, 14769015 remain, 2000000 are dead but not yet removable
removable cutoff: 929, which was 3 XIDs old when operation ended
new relfrozenxid: 929, which is 11 XIDs ahead of previous value
frozen: 0 pages from table (0.00% of total) had 0 tuples frozen
index scan needed: 49181 pages from table (15.00% of total) had 2999999 dead item identifiers removed
index "pgbench_accounts_pkey": pages: 54840 in total, 8224 newly deleted, 8224 currently deleted, 0 reusable
I/O timings: read: 174.219 ms, write: 0.000 ms
avg read rate: 26.491 MB/s, avg write rate: 22.489 MB/s
buffer usage: 276192 hits, 41175 misses, 34955 dirtied
WAL usage: 123002 records, 57432 full page images, 75538789 bytes
system usage: CPU: user: 0.64 s, system: 0.27 s, elapsed: 12.14 sПример записи из более ранних версий PostgreSQL:
[17656][autovacuum worker][5/463][0] LOG: automatic vacuum of table "testdb.public.pgbench_accounts": index scans: 1
pages: 0 removed, 327869 remain, 0 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 14740860 remain, 2000000 are dead but not yet removable, oldest xmin: 760
index scan needed: 49181 pages from table (15.00% of total) had 2999999 dead item identifiers removed
index "pgbench_accounts_pkey": pages: 54840 in total, 8224 newly deleted, 8224 currently deleted, 0 reusable
I/O timings: read: 488.030 ms, write: 238.542 ms
avg read rate: 55.609 MB/s, avg write rate: 21.009 MB/s
buffer usage: 192958 hits, 124428 misses, 47008 dirtied
WAL usage: 122981 records, 0 full page images, 19019531 bytes
system usage: CPU: user: 1.14 s, system: 0.80 s, elapsed: 17.48 sКак из логов выжать максимум
Для большинства приложений с большой нагрузкой рекомендуется не просто складывать их в папку ради галочки, а использовать их. Доступность и возможность поиска по логам критически важны для отладки и, как вы уже видели выше, очень полезны для анализа производительности. Логи похожи на страховку: они не нужны каждый день, но когда возникает проблема — вы рады, что они у вас есть.
pgBadger
Есть один open-source проект для анализа логов PostgreSQL — pgBadger. Если вам приходилось просматривать логи вручную, этот инструмент покажется настоящей магией. Он преобразует вывод PostgreSQL в HTML-страницу с интерактивными графиками.
Обычно его запускают периодически или по запросу, чтобы проанализировать логи PostgreSQL и сгенерировать отчёты в HTML.
Если вы используете управляемый облачный сервис PostgreSQL и у вас есть возможность выгружать логи в файл, можно применять pgBadger. В Crunchy Bridge, например, можно «подключить хвост» логов напрямую к pgBadger:
-- отправить логи CLI в локальный текстовый файл
cb logs qzyqhjdg3focnta3zvleomq > pglogs.txt
-- pgBadger читает текстовый файл и формирует html-отчёт
pgbadger -f syslog pglogs.txt -o out.htmlСторонние инструменты для сбора логов
Есть масса сервисов, которые берут на себя хранение, парсинг и быстрый поиск по логам. Наши клиенты успешно используют pganalyze, Datadog, Honeybadger и другие. Эти решения могут работать как агент, контейнер-под или сервис, экспортирующий логи. Для облачного хостинга такой подход особенно удобен.
-- настройка передачи логов в syslog
log_destination = 'syslog'; Хранилища данных для логов
В больших проектах логи сами по себе превращаются в отдельный проект. Некоторые команды выбирают самостоятельный хостинг и организацию запросов к логам. Системы вроде Snowflake, ClickHouse, Crunchy Data Warehouse и другие позволяют хранить и обрабатывать высоконагруженные логи средствами SQL. А если хранить их в object storage в виде файлов — получается довольно бюджетно.
Сводка рекомендуемых настроек логирования
Ниже — основные параметры из статьи. Но не копируйте вслепую: всё зависит от вашей нагрузки и окружения.
-- включить сборщик логов
ALTER SYSTEM SET logging_collector = 'on';
-- логировать системные ошибки
ALTER SYSTEM SET log_min_messages = 'warning'; («в продакшене часто выставляют error, чтобы сократить шум»)
-- логировать все изменения структуры данных
ALTER SYSTEM SET log_statement = 'ddl';
-- логировать полный текст запросов при ошибках SQL
ALTER SYSTEM SET log_min_error_statement = 'ERROR';
-- имя файла лога
ALTER SYSTEM SET log_filename = 'postgres-%Y-%m-%d';
-- добавить в префикс имя БД и PID процесса
ALTER SYSTEM SET log_line_prefix = '%m [%p] %q%u@%d ';
-- ежедневная ротация логов
ALTER SYSTEM SET log_rotation_age = '1d';
-- включить pgaudit.log
ALTER SYSTEM SET pgaudit.log = 'ddl';
-- логировать запросы длиннее 1000 мс
ALTER SYSTEM SET log_min_duration_statement = '1000';
-- логировать ожидания блокировок
ALTER SYSTEM SET log_lock_waits = 'on';
-- логировать временные файлы больше 4 МБ
ALTER SYSTEM SET log_temp_files = '4096';
-- логировать планы запросов дольше 1000 мс
ALTER SYSTEM SET auto_explain.log_min_duration = '1000ms';
-- настроить вывод логов в syslog или другой источник для поиска
ALTER SYSTEM SET log_destination = 'syslog'; Заключение
Главное, что стоит запомнить: PostgreSQL умеет логировать почти всё, и это гибко настраивается. Но включайте только то, что реально помогает. Архивируйте логи, используйте внешние системы для поиска, а старые файлы удаляйте по ротации.
Цена логов — в диске и деньгах. Они быстро разрастаются, если не следить. Баланс простой: храните то, что нужно, и выбрасывайте остальное.
Если цель — ускорение, смотрите на медленные запросы и их планы (через auto_explain), а ещё на временные файлы — они подскажут, где PostgreSQL упёрся в память.
Не забывайте про дев и стейдж: там логи позволяют поймать баги и проверить планы, не тратя ресурсы боевого контура.
Логи в PostgreSQL быстро убеждают: ошибки — это не только проблемы, но и подсказки для оптимизации. Если хочется глубже разобраться в администрировании, настройке и ускорении Postgres в боевых системах, обратите внимание на курс «PostgreSQL для администраторов баз данных и разработчиков» — один из самых востребованных для повышения квалификации. На странице курса можно пройти вступительный тест для оценки своих знаний.
А пока есть возможность заглянуть на бесплатные практические открытые уроки курса — в прямом эфире и с разбором реальных кейсов:
27 августа в 20:00 — Инкрементальное бекапирование средствами PostgreSQL. Записаться
9 сентября в 20:00 — Механизмы блокировок в PostgreSQL. Записаться
24 сентября в 20:00 — Маленькие хитрости GROUP BY. Записаться