Используется просроченная статистика вместо текущей так как сборщик статистики не отвечает

Анализ статистики для мониторинга PostgreSQL

Для эффективной работы системы важно отслеживать основные показатели производительности её базы данных. В Postgre SQL существует готовая подсистема, которая осуществляет сбор информации о работе сервера БД, а также предоставляет к ней доступ в виде готовых представлений и функций. Регулярный анализ собранной статистики может помочь администратору и разработчику найти наиболее уязвимые места при ежедневном эксплуатировании базы данных. В этой статье я расскажу об основных статистиках, которые накапливаются в PostgreSQL , в качестве примеров я приведу SQL -запросы на выборку основных показателей работы базы данных, а также затрону встроенные инструменты визуализации статистики в современных GUI для PostgreSQL .

Базовые статистики для анализа работы БД

В PostgreSQL сборщик статистики предоставляет доступ к накопленным данным через предопределённые представления. Основные из них показаны ниже на схеме:

• pg_stat_activity – предоставление информации о текущей активности серверного процесса, включая его состояние и текущий запрос;
• pg_stat_database – представление статистических данных по каждой базе данных на сервере;
• pg_stat_all_indexes – представление статистических данных по каждому индексу;
• pg_stat_all_tables – представление статистических данных по каждой таблице;
• pg_stat_wal – представление статистических данных о работе журнала предзаписи (Write-Ahead Log ging ) в кластере;
• pg_stat_user_functions – представление статистических данных о выполнении функций.

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

Примеры запросов для анализа основных показателей БД

Нагрузка на базу данных

Для понимания нагрузки на базу данных хорошо знать общий объём транзакций за определенный период времени. Для получения этих данных можно использовать следующий запрос:

SELECT datname, xact_commit + xact_rollback , stats_reset FROM pg_stat_database; 

Здесь сумма xact_commit и количество xact_rollback – суммарное количество транзакций за период с момента сброса статистических данных stats_reset.

Распределение серверных процессов по состояниям

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

• active — выполнение запроса;
• idle — ожидание новой команды от клиента;
• idle in transaction — серверный процесс находится внутри транзакции, но в настоящее время не выполняет никакой запрос;
• idle in transaction (aborted) — серверный процесс находится внутри транзакции, но один из операторов в транзакции вызывал ошибку;
• fastpath function call — выполнение fast-path функции;
• disabled – у серверного процесса отключён параметр track_activities.

Получить общее количество соединений по состояниям позволяет следующая группировка:

SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

Длительность текущих активных транзакций и запросов

Длительность текущих активных транзакций и запросов можно проанализировать, выполнив запрос:

SELECT datname, usename, now() - xact_start AS TransactionDuration, now() - query_start as QueryDuration FROM pg_stat_activity WHERE state = 'active';

Определение наиболее нагруженных таблиц

Статистику обращений к таблицам базы данных предоставляет pg_stat_all_tables. Представление позволяет оценить, например, общий объём insert, update, delate операций к таблице. Определить наиболее часто используемые таблицы в БД можно с помощью запроса:

SELECT relname, n_tup_upd+n_tup_ins+n_tup_del AS operationsAmount FROM pg_stat_all_tables ORDER BY operationsAmount DESC;

Отношение сканирований по индексам к последовательным сканированиям

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

SELECT relname, seq_scan, idx_scan, idx_scan/seq_scan as IndexStat FROM pg_stat_all_tables WHERE seq_scan <> 0 ORDER BY IndexStat DESC;

Отслеживание устаревших индексов

Полную информацию по созданным в базе данных индексам содержит представление pg_stat_all_indexes. Устаревшие индексы можно обнаружить с помощью запроса:

SELECT indexrelname, relname, idx_tup_read/idx_tup_fetch as stats FROM pg_stat_all_indexes WHERE idx_tup_fetch <> 0 ORDER BY stats DESC; 

Здесь idx_tup_read/idx_tup_fetch – это отношение записей из индекса, возвращённых в запросах по этому индексу, к общему числу записей, для которых пришлось обращаться к родительским таблицам. Если этот коэффициент меньше единицы, значит много данных читается в обход индекса, поэтому его необходимо обновить.

Мониторинг в GUI-клиентах

Для администраторов баз данных и программистам важно быстро определять производительность СУБД, анализировать проблемы с дисковым пространством, контролировать количество подключений и т.д. Поэтому современные GUI-клиенты предлагают собственные панели мониторинга для СУБД. Наиболее развитые системы мониторинга существуют в следующих графических приложениях:

Бесплатный GUI -клиент с открытым исходным кодом

Linux , Windows , macOS

Предопределенный дашборд ( серверные сеансы, блокировки, транзакции в секунду; операции с записями), отображение дополнительной статистики

Бесплатный GUI -клиент с дополнительными платными версиями.

Linux, Windows, macOS

Предопределенный дашборд (серверные сеансы, блокировки, транзакции в секунду), возможность доработки дашбордов на базе предопределённых дашбордов.

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

• Server sessions — показывает активные/неактивные сеансы сервера;
• Transactions per second – отображает количество транзакций в секунду;
• Block IO – отображает количество блокировок при операциях ввода/вывода в секунду.

Предопределённые виджеты изменять в DBeaver нельзя, однако можно создать новый виджет путём копирования шаблона. В диалоговом окне можно настроить новые параметры шаблона и реализовать свой запрос для получения данных виджета:

Аналогичные шаблоны также реализованы и в клиенте pgAdmin, однако дополнительно в нём присутствуют следующие виджеты:

• Tuples in – отображает количество записей, вставленных, обновленных и удаленных на сервере или в базе данных;
• Tupels out – отображает количество записей, полученных и возвращенных с сервера или базы данных.

Также в pgAdmin на вкладке «Статистика» отображается готовая сводная статистика для выбранного элемента из дерева БД.

• PID – ИД серверного процесса;
• User – имя пользователя;
• Database – название базы данных;
• Backends – число текущих клиентских подключений к БД;
• Backend start – время старта серверного процесса;
• Xact Committe

Для пользователя доступны для отслеживания следующие показатели: d – число зафиксированных транзакций за последнюю неделю;

• Xact Rolled Back – число отменённых транзакций за последнюю неделю;
• Blocks Read – число блоков, считанных с диска за последнюю неделю;
• Blocks Hit – число блоков, считанных из оперативной памяти за последнюю неделю;
• Tuples Returned – количество, возвращённых записей за последнюю неделю;
• Tuples Fetched – количество записей, выбранных за последнюю неделю;
• Tuples Inserted – количество вставленных записей в базе данных за последнюю неделю;
• Tuples Updated – количество обновлённых записей в базе данных за последнюю неделю;
• Tuples Deleted – количество удалённых записей в базе данных за последнюю неделю;
• Last statistics – дата и время последнего сброса накопленных статистик в базе данных.

Заключение

В PostgreSQL сборщик статистики предоставляет полноценную информацию о работе сервера, которую можно регулярно анализировать. Также дополнительно включив модуль pg_stat_statements, СУБД будет отслеживать статистику планирования и выполнения сервером всех операторов SQL. Отдельно стоит выделить базовые возможности GUI-клиентов по мониторингу сервера базы данных. Используя базовые представления статистики PostgreSQL, они предоставляют пользователю готовую информацию в виде дашбордов, что позволяет динамически отслеживать работу сервера и выявлять ошибки.

Использование и настройка PostgreSQL

pg_config — эта утилита выводит параметры (например, с какими параметрами скомпилирован PostgreSQL) конфигурации текущей установленной версии PostgreSQL. Находится в пакете postgresql-devel (для ОС Fedora Linux) postgresql-server-dev-8.3(для ОС Debian 5).

pg_ctl является утилитой для запуска, остановки, перезапуска, перезагрузки конфигурационных файлов, информирования о состоянии сервера PostgreSQL, или отправки сигналов PostgreSQL- процессу. Показать статус севера:

# sudo -u postgres pg_ctl status -D /var/lib/pgsql/data

PostgreSql postgresql.conf — настройки сервера.

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

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

Все объекты (таблицы, индексы …) базы данных в PostgreSQL хранятся в каталоге data/base/OID, т.е. названием каталога содержащего БД, будет не имя БД (как в Движок БД MySQL), а номер (OID) БД.

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

xmin — хранит номер транзакции, в которой запись была создана.
xmax — хранит номер транзакции, в которой запись была удалена или изменена.

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

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

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

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

Запись вида «host». host <имя базы данных> [аргумент для авторизации]

Запись типа «local». Эта запись определяет авторизацию доступа к базе данных локальных пользователей. Идентично «host», за исключением того, что IP- адрес и маска адреса опущены за ненадобностью.

trust в этом режиме авторизации доступа не производится. Соединение считается доверительным.

Каждая запись в файле pg_hba.conf должна полностью умещаться в одной строке. Перенос записей на другую строку запрещен.

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

Разрешить всем пользователям доступ с любого хоста к всем базам данных по логину и паролю

# TYPE DATABASE USER ADDRESS METHOD host all all all md5

Разрешить пользователю(dbuser) доступ к базе данных(mother) с любого хоста по логину и паролю

host mother dbuser all md5

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

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

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

postgres=# show server_encoding; server_encoding ----------------- UTF8 (1 row)

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

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

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

pgAdmin — GUI для PostgreSQL. Лучший графический клиент из существующих.

DBeaver Community Free Universal Database Tool — бесплатный многоплатформенный инструмент для работы с базами данных для разработчиков, администраторов баз данных, аналитиков и всех, кому необходимо работать с базами данных. Поддерживает все популярные базы данных: MySQL, PostgreSQL, SQLite, Oracle, DB2, SQL Server, Sybase, MS Access, Teradata, Firebird, Apache Hive, Phoenix, Presto и др.

phpPgAdmin — веб- приложение с открытым кодом, написанное на языке PHP и представляющее собой веб- интерфейс для администрирования СУБД PostgreSQL.

OpenOffice и SDBC. Для прямого доступа из OpenOffice к PostgreSQL без промежуточного уровня в виде ODBC/JDBC драйверов разрабатывается postgresql-sdbc драйвер.

# apt install openoffice.org-sdbc-postgresql

DbVisualizer в бесплатной версии ограничен набор функций.

psql

psql — PostgreSQL interactive terminal.

PL/pgSQL ( (Procedural Language/PostGres Structured Query Language) — процедурное расширение языка SQL, используемое в СУБД PostgreSQL.

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

Подключиться к локальному серверу.

$ sudo -u postgres psql psql (8.4.5) Type "help" for help. postgres=#

Подключиться к удаленному серверу.

$ psql -h 192.168.1.20 -U postgres

В psql узнать подробности об определённом SQL команде можно при помощи \h (ключ \? выводит помощь по мета-командам), например для drop table:

postgres=# \h drop table Command: DROP TABLE Description: remove a table Syntax: DROP TABLE [ IF EXISTS ] name [, . ] [ CASCADE | RESTRICT ]

Пример выполнения SQL запроса из командой строки

# sudo -u postgres psql -d mybd --command="select * from pg_stat_user_indexes where schemaname='public';"

Как в PostgreSQL посмотреть список пользователей?

postgres=# select * from pg_shadow; postgres=# \du

Вывести список баз данных:

postgres=# select * from pg_database; или postgres=# \l Из командной строки: # psql -U postgres -A -q -t -c "select datname from pg_database" или: # psql -l

Вывести название текущей базы данных:

SELECT current_database();

Вывести имя (идентификатор) текущего пользователя:

SELECT current_user;

Вывести список таблиц активной базы данных (если после ключа \d указать имя таблицы — будет выведена структура таблицы):

postgres=# \dt или select * from pg_tables; # будут выведены все таблицы, в том числе и системные select tablename from pg_tables where schemaname='public';

Удалить БД testbd777

# sudo -u postgres dropdb testbd777

Залить(восстановить) данные в БД c именем test777

# sudo -u postgres psql test777 < lost_cdr.sql

regexp_split_to_table. В текстовом поле ipaddr хранятся IP адреса разделенные ; т.е. 1 строка - много IP. Запрос выводит все IP в столбик т.н. 1 строка - 1 IP

SELECT regexp_split_to_table(ipaddr, E';') as ip FROM peers;

Вывести версию Postgresql:

postgres=# SELECT version(); PostgreSQL 8.4.8 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2), 64-bit

Пример экранирования одинарной кавычки в слове Кот-д'Ивуар. В PHP для экранирования спецсимволов используется функция pg_escape_string().

$ psql -U postgres -d mydb --command="INSERT INTO countries (english,russian) VALUES ('Ivory Coast', 'Кот-д''Ивуар');"

Для смены активной базы данных в psql, применяется ключ \с
Вывести время запуска сервера и uptime

SELECT pg_postmaster_start_time(); pg_postmaster_start_time ------------------------------- 2013-08-21 14:20:45.451467+00 SELECT current_timestamp - pg_postmaster_start_time() AS uptime;

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

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

select * from pg_stat_activity; # посмотреть все запросы select * from pg_stat_activity WHERE current_query like 'SELECT%'; # посмотреть все SELECT запросы select * from pg_stat_activity WHERE current_query like 'INSERT%'; # снять все активные select запросы SELECT pg_cancel_backend(procpid) as x FROM pg_stat_activity WHERE current_query like 'SELECT%'; # снять запрос VACUUM SELECT pg_cancel_backend(procpid) as x FROM pg_stat_activity WHERE current_query like 'VACUUM%';

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

# ps auxww | grep ^postgres . postgres 15724 97.7 11.3 2332996 1871476 ? Rs 07:50 1:53 postgres: postgres mybd 127.0.0.1(53624) SELECT . # kill 15724

procpid содержит PID процесса, которому можно сделать kill при необходимости. Например PID можно узнать запросом(отсортируем по длительности выполнения)

select datname,procpid,now()-query_start as duration,current_query from pg_stat_activity order by duration DESC;

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

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

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

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

# nano delprices.sql BEGIN; DELETE FROM prices WHERE ratesheet_id=2; DELETE FROM ratesheets WHERE > Выполним транзакцию для test777:

# sudo -u postgres psql -l # sudo -u postgres psql test777 < delprices.sql

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

Размер базы данных PostgreSQL, таблицы, столбца, количество строк. Мониторинг использования диска.

Лог файлы

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

Мониторинг

bucardo.org check_postgres - Perl cкрипт для мониторинга более 20 параметров, определяющих состояние СУБД PostgreSQL.

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

# watch -n 1 'ps auxww | grep ^postgres' postgres 14164 0.0 0.0 188492 5296 ? S Dec13 0:46 /usr/bin/postmaster -p 5432 -D /var/lib/pgsql/data postgres 14166 0.0 0.0 159904 1264 ? Ss Dec13 0:05 postgres: logger process postgres 14168 0.0 0.1 188636 27208 ? Ss Dec13 0:49 postgres: writer process postgres 14169 0.0 0.0 188492 1348 ? Ss Dec13 0:23 postgres: wal writer process postgres 14170 0.0 0.0 188804 1752 ? Ss Dec13 0:17 postgres: autovacuum launcher process postgres 14171 0.0 0.0 160176 1468 ? Ss Dec13 0:45 postgres: stats collector process postgres 21596 0.0 0.1 190228 30476 ? Ss Dec27 0:58 postgres: postgres mbill 127.0.0.1(37047) idle postgres 21597 0.0 0.0 189716 5672 ? Ss Dec27 0:00 postgres: postgres mbill 127.0.0.1(37048) idle

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

postgres: «пользователь» «база» «хост» «статус»

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

idle - ожидание команды от клиента,

idle in transaction - ожидание команды от клиента внутри транзакции (между BEGIN и окончанием транзакции),

SQL- команда - выполняется эта команда, например, SELECT,

waiting - ждём когда разблокируется занятая другим процессом таблица. Для уточнения из-за чего возникла блокировка, нужно анализировать представление pg_locks.

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

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

Statistics Collector (Standard Statistics Views): описание системных таблицах, собирающих информацию об активности базы данных.

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

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

Для каких таблиц стоит создать новые индексы (индикатором служит большое количество полных просмотров и большое количество прочитанных блоков).

Какие индексы вообще не используются в запросах. Их имеет смысл удалить, если, конечно, речь не идёт об индексах, обеспечивающих выполнение ограничений PRIMARY KEY и UNIQUE.

Достаточен ли объём буфера сервера.

Возможен "дедуктивный" подход, при котором сначала создаётся большое количество индексов, а затем неиспользуемые индексы удаляются.

Для сброса системной статистики(файл pgstat.stat) в ноль применяется команда

select pg_stat_reset();

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

select schemaname,viewname,viewowner from pg_views where schemaname='pg_catalog';

pg_stat_activity - Каждая строка показывает: процесс сервера, OID базы данных, имя базы данных, ID процесса, OID пользователя, имя пользователя, имя приложения, адрес клиента и порт,время, текущею транзакцию, текущий запрос, статус процесса, текст запроса. Колонки показывающие данные текущего запроса доступны если параметр track_activities включен. Эти колонки доступны только для суперпользователя или пользователя владельца процесса.

select * from pg_stat_activity; # Вывести запросы отсортированные по длительности выполнения select datname,client_addr,now()-query_start as duration,current_query from pg_stat_activity order by duration DESC;

pg_stat_bgwriter

pg_stat_database - Одна строка на кажду БД. Выводит OID базы данных, имя базы данных, количество процессов подключенных к базе(numbackends), кол-во транзакций примененных(xact_commit) и отмененных(xact_rollback), количество прочитанных блоков(blks_read), количество попаданий в буфер(blks_hit), количество выбранных(tup_returned), переданных(tup_fetched), добавленных(tup_inserted), обновленных(tup_updated) и удаленных строк(tup_deleted).

select * from pg_stat_database;

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

select datname, case when blks_read = 0 then 0 else blks_hit/blks_read end as ratio from pg_stat_database;

pg_stat_all_tables - Для каждой таблицы в текущей базе данных (включая TOAST таблицы): OID таблицы(relid), схема(schemaname) и имя таблицы(relname), количество последовательны просмотров(seq_scan), количество строк выбранных запросами(seq_tup_read), количество просмотров индексов (все индексы данной таблицы)(idx_scan), количество строк выбранных через сканирование индексов(idx_tup_fetch), количество: пересечений строк(n_tup_ins), обновленных(n_tup_upd), удаленных строк(n_tup_del), количество обновленных HOT строк(n_tup_hot_upd), количество живых(n_live_tup) и мертвых строк(n_dead_tup), время последнего ручного vacuum, время последнего автоматического vacuum, время последнего ручного analyze, время последнего автоматического analyze. Запросы для активной БД:

select * from pg_stat_all_tables where schemaname='public'; select relname,last_vacuum,last_autovacuum,last_analyze,last_autoanalyze from pg_stat_all_tables where schemaname='public';

pg_stat_sys_tables - То же что и pg_stat_all_tables, только системные таблицы.

pg_stat_user_tables - То же что и pg_stat_all_tables, только пользовательские таблицы. Статистика seq scan/index scan. Список по таблицам: какое количество запросов к ним было выполнено посредством последовательного просмотра; какое количество запросов было выполнено с использованием индексов; а также отношение этих двух чисел. Позволяет оценить, все ли нужные индексы созданы в данной таблице. Если ваши таблицы содержат более нескольких тысяч рядов, последовательный просмотр будет выполняться медленнее просмотра индекса, поэтому в идеальном случае seqscan-ов в таких таблицах быть не должно. Если у вас они все же есть, анализируйте запросы к таким таблицам и создавайте соответствующие индексы. При этом важно не перестараться: чем больше индексов по колонкам таблицы, тем дороже становятся операции обновления данных. Также не забывайте, что после создания индекса таблице нужно делать ANALYZE, иначе планировщик запросов не заметит изменений в структуре таблицы.

select relname,seq_scan,idx_scan, case when idx_scan = 0 then 100 else seq_scan/idx_scan end as ratio from pg_stat_user_tables order by ratio desc; select relname,seq_scan,idx_scan, case when idx_scan = 0 then 100 else seq_scan/idx_scan end as ratio,n_live_tup,n_dead_tup from pg_stat_user_tables order by ratio desc;

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

select relname,n_tup_ins,n_tup_upd,n_tup_del from pg_stat_user_tables order by n_tup_ins desc;

pg_stat_all_indexes - Поможет оценить эффективность и частоту использования индексов при реальной работе. Для каждого индекса текущей базы: OID таблицы и OID, схема, имя таблица и индекса, количество просмотров индекса(idx_scan), количество записей возвращенных при сканировании индекса(idx_tup_read), количество живых строк(idx_tup_fetch) таблицы полученных простым сканированием индексов используя этот индекс.

select * from pg_stat_all_indexes;

pg_stat_sys_indexes - То же что и pg_stat_all_indexes, только системные таблицы.
pg_stat_user_indexes - То же что и pg_stat_all_indexes, только пользовательские таблицы.

select * from pg_stat_user_indexes where schemaname='public';

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

select relname,indexrelname,idx_tup_read,idx_tup_fetch,(idx_tup_read-idx_tup_fetch) as diff, CASE WHEN idx_tup_read=0 THEN 0 ELSE (idx_tup_read::float4-idx_tup_fetch)/idx_tup_read END as r FROM pg_stat_user_indexes ORDER BY r desc;

pg_statio_all_tables - Для каждой таблицы текущей базы данных (включая TOAST таблицы), OID таблицы, схема и имя таблицы, количество блоков прочитанных с диска, количество попаданий в буфер, количество блоков прочитанных с диска и попавших в буфер для всех индексов таблицы, количество блоков прочитанных с диска и попавших в буфер that table’s auxiliary TOAST table (if any), количество блоков прочитанных с диска и попавших в буфер для индекса TOAST таблиц.

pg_statio_sys_tables - То же что и pg_statio_all_tables, только системные таблицы.
pg_statio_user_tables - То же что и pg_statio_all_tables, только пользовательские таблицы.

pg_statio_all_indexes - Для каждого индекса текущей базы данных: OID таблицы и индекса, имя таблицы и индекса, количество блоков прочитанных с диска и попаданий в буфер.

pg_statio_sys_indexes - То же что и pg_statio_all_indexes, только системные таблицы.
pg_statio_user_indexes - То же что и pg_statio_all_indexes, только пользовательские таблицы

pg_statio_all_sequences - Для каждой последовательности в текущей базе данных: OID последовательности, схема и имя последовательности, количество прочитанных блоков с диска и попаданий в буфер.

pg_statio_sys_sequences - То же что и pg_statio_all_sequences, только системные таблицы.
pg_statio_user_sequences - То же что и pg_statio_all_sequences, только пользовательские таблицы.
pg_stat_user_functions - Значения времени указано в миллисекундах.
pg_locks блокировки в PostgreSQL - информация о блокировках в базе данных.

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

Explicit Locking - документация о типах блокировок в PostgreSQL.

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

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

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

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

Блокировка таблиц возможна только в транзакциях. Выполнение команды LOCK TABLE вне транзакционного блока не приводит к ошибке, но установленная блокировка немедленно снимается. Транзакция создается командой BEGIN; команда COMMIT фиксирует изменения в базе данных и снимает блокировку.

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

ACCESS SHARE MODE. Устанавливается автоматически командой SELECT для таблиц, из которых производится выборка данных. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровня ACCESS EXCLUSIVE MODE.

ROW SHARE MODE. Устанавливается автоматически командами SELECT, содержащими секцию FOR UPDATE или FOR SHARE. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE.

ROW EXCLUSIVE MODE. Устанавливается автоматически командами UPDATE, INSERT и DELETE. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и CREATE INDEX. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней SHARE MODE, SHARE ROW EXCLUSIVE MODE, EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE.

SHARE UPDATE EXCLUSIVE MODE . Устанавливается автоматически командами VACUUM (без FULL), ANALYZE и CREATE INDEX CONCURRENTLY.

SHARE MODE. Устанавливается автоматически командами CREATE INDEX (без CONCURRENTLY). В заблокированных таблицах запрещается выполнение команд INSERT, UPDATE, DELETE, ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней ROW EXCLUSIVE MODE, SHARE ROW EXCLUSIVE MODE, EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE.

SHARE ROW EXCLUSIVE MOOE. Специальный режим блокировки, практически идентичный режиму EXCLUSIVE MODE, но допускающий установку параллельных блокировок уровня ROW SHARE MODE.

EXCLUSIVE MODE. Запрещает выполнение команд INSERT, UPDATE, DELETE, CREATE INDEX, ALTER TABLE, DROP TABLE и VACUUM, а также команд SELECT с секцией FOR UPDATE. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней ROW SHARE MODE, ROW EXCLUSIVE MODE, SHARE MODE, SHARE ROW EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE.

ACCESS EXCLUSIVE MODE. Устанавливается автоматически командами ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц запрещаются любые команды или параллельные блокировки любого уровня.

Используется просроченная статистика вместо текущей так как сборщик статистики не отвечает

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

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

28.2.1. Конфигурация системы сбора статистики

Поскольку сбор статистики несколько увеличивает накладные расходы при выполнении запроса, есть возможность настроить СУБД так, чтобы выполнять или не выполнять сбор статистической информации. Это контролируется конфигурационными параметрами, которые обычно устанавливаются в файле postgresql.conf . (Подробно установка конфигурационных параметров описывается в Главе 19.)

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

Параметр track_counts определяет необходимость сбора статистики по обращениям к таблицам и индексам.

Параметр track_functions включает отслеживание использования пользовательских функций.

Параметр track_io_timing включает мониторинг времени чтения и записи блоков.

Обычно эти параметры устанавливаются в postgresql.conf , поэтому они применяются ко всем серверным процессам, однако, используя команду SET , их можно включать и выключать в отдельных сессиях. (Для того чтобы обычные пользователи не скрывали свою работу от администратора СУБД, изменять эти параметры с помощью команды SET могут только суперпользователи.)

Сборщик статистики использует временные файлы для передачи собранной информации другим процессам PostgreSQL . Имя каталога, в котором хранятся эти файлы, задаётся параметром stats_temp_directory, по умолчанию он называется pg_stat_tmp . Для повышения производительности stats_temp_directory может указывать на каталог, расположенный в оперативной памяти, что сокращает время физического ввода/вывода. При остановке сервера постоянная копия статистической информации сохраняется в подкаталоге pg_stat , поэтому статистику можно хранить на протяжении нескольких перезапусков сервера. Когда восстановление выполняется при запуске сервера (например, после непосредственного завершения работы, катастрофического отказа сервера, и восстановлении на заданную точку во времени), все статистические данные счётчиков сбрасываются.

28.2.2. Просмотр статистики

Для просмотра текущего состояния системы предназначены несколько предопределённых представлений, которые перечислены в Таблице 28.1. В дополнение к ним есть несколько других представлений, перечисленных в Таблице 28.2, позволяющих просмотреть результаты сбора статистики. Кроме того, на базе нижележащих статистических функций можно создать собственные представления, как описано в Подразделе 28.2.3.

Наблюдая собранные данные в сборщике статистики, важно понимать, что эта информация обновляется не сразу. Каждый серверный процесс передаёт новые статистические данные сборщику статистики непосредственно перед переходом в режим ожидания; то есть запрос или транзакция в процессе выполнения не влияют на отображаемые данные статистики. К тому же, сам сборщик статистики формирует новый отчёт не чаще, чем раз в PGSTAT_STAT_INTERVAL миллисекунд (500 мс, если этот параметр не изменялся при компиляции сервера). Так что отображаемая информация отстаёт от того, что происходит в настоящий момент. Однако информация о текущем запросе, собираемая с параметром track_activities , всегда актуальна.

Ещё одним важным моментом является то, что когда в серверном процессе запрашивают какую-либо статистику, сначала он получает наиболее свежий моментальный снимок от сборщика статистики и затем до окончания текущей транзакции использует этот снимок для всех статистических представлений и функций. Так что на протяжении одной транзакции статистическая информация меняться не будет. Подобным же образом информация о текущих запросах во всех сессиях собирается в тот момент, когда она впервые запрашивается в рамках транзакции, и эта же самая информация будет отображаться на протяжении всей транзакции. Это не ошибка, а полезное свойство СУБД, поскольку оно позволяет выполнять запросы к статистическим данным и сравнивать результаты, не беспокоясь о том, что статистические данные изменяются. Но если для каждого запроса вам нужны новые результаты, то их следует выполнять вне любых транзакционных блоков. Или же можно вызывать функцию pg_stat_clear_snapshot (), которая сбросит ранее полученный снимок статистики в текущей транзакции (если он был). При следующем обращении к статистической информации будет сформирован новый моментальный снимок.

Через представления pg_stat_xact_all_tables , pg_stat_xact_sys_tables , pg_stat_xact_user_tables , и pg_stat_xact_user_functions транзакции также доступна её собственная статистика (ещё не переданная сборщику статистики). Данные в этих представлениях ведут себя не так, как описано выше; наоборот, в течение транзакции они постоянно обновляются.

Таблица 28.1. Динамические статистические представления

Имя представления	Описание
pg_stat_activity	Одна строка для каждого серверного процесса c информацией по текущей активности процесса, такой как состояние и текущий запрос. За подробностями обратитесь к pg_stat_activity.
pg_stat_replication	По одной строке для каждого процесса-передатчика WAL со статистикой по репликации на ведомом сервере, к которому подключён этот процесс. За подробностями обратитесь к pg_stat_replication.
pg_stat_wal_receiver	Только одна строка со статистикой приёмника WAL, полученной с сервера, на котором работает приёмник. За подробностями обратитесь к pg_stat_wal_receiver.
pg_stat_ssl	Одна строка для каждого подключения (обычного и реплицирующего), в которой показывается информация об использовании SSL для данного подключения. За подробностями обратитесь к pg_stat_ssl.
pg_stat_progress_vacuum	По одной строке с текущим состоянием для каждого обслуживающего процесса (включая рабочие процессы автоочистки), в котором работает VACUUM . См. Подраздел 28.4.1.

Таблица 28.2. Представления собранной статистики

Имя представления	Описание
pg_stat_archiver	Только одна строка со статистикой о работе активности процесса архивации WAL. Более подробно смотрите pg_stat_archiver.
pg_stat_bgwriter	Только одна строка со статистикой о работе фонового процесса записи. Более подробно смотрите pg_stat_bgwriter.
pg_stat_database	Одна строка для каждой базы данных со статистикой на уровне базы. Более подробно смотрите pg_stat_database.
pg_stat_database_conflicts	По одной строке на каждую базу данных со статистикой по отменам запросов, выполненным вследствие конфликта с процессами восстановления на ведомых серверах. Более подробно смотрите pg_stat_database_conflicts.
pg_stat_all_tables	По одной строке на каждую таблицу в текущей базе данных со статистикой по обращениям к этой таблице. Более подробно смотрите pg_stat_all_tables.
pg_stat_sys_tables	Аналогично pg_stat_all_tables , за исключением того, что отображаются только системные таблицы.
pg_stat_user_tables	Аналогично pg_stat_all_tables , за исключением того, что отображаются только пользовательские таблицы.
pg_stat_xact_all_tables	Подобно pg_stat_all_tables , но подсчитывает действия, выполненные в текущей транзакции к настоящему моменту (которые ещё не вошли в pg_stat_all_tables и связанные представления). Столбцы для числа живых и мёртвых строк, а также количества операций очистки и сбора статистики, в этом представлении отсутствуют.
pg_stat_xact_sys_tables	Аналогично pg_stat_xact_all_tables , за исключением того, что отображаются только системные таблицы.
pg_stat_xact_user_tables	Аналогично pg_stat_xact_all_tables , за исключением того, что отображаются только пользовательские таблицы.
pg_stat_all_indexes	По одной строке для каждого индекса в текущей базе данных со статистикой по обращениям к этому индексу. Более подробно смотрите pg_stat_all_indexes.
pg_stat_sys_indexes	Аналогично pg_stat_all_indexes , за исключением того, что показываются только индексы по системным таблицам.
pg_stat_user_indexes	Аналогично pg_stat_all_indexes , за исключением того, что показываются только индексы по пользовательским таблицам.
pg_statio_all_tables	По одной строке для каждой таблицы в текущей базе данных со статистикой по операциям ввода/вывода для этой таблицы. Более подробно смотрите pg_statio_all_tables.
pg_statio_sys_tables	Аналогично pg_statio_all_tables , за исключением того, что показываются только системные таблицы.
pg_statio_user_tables	Аналогично pg_statio_all_tables , за исключением того, что показываются только пользовательские таблицы.
pg_statio_all_indexes	По одной строке для каждого индекса в текущей базе данных со статистикой по операциям ввода/вывода для этого индекса. Более подробно смотрите pg_statio_all_indexes.
pg_statio_sys_indexes	Аналогично pg_statio_all_indexes , за исключением того, что показываются только индексы по системным таблицам.
pg_statio_user_indexes	Аналогично pg_statio_all_indexes , за исключением того, что показываются только индексы по пользовательским таблицам.
pg_statio_all_sequences	По одной строке для каждой последовательности в текущей базе данных со статистикой по операциям ввода/вывода для этой последовательности. Более подробно смотрите pg_statio_all_sequences.
pg_statio_sys_sequences	Аналогично pg_statio_all_sequences , за исключением того, что показываются только системные последовательности. (В настоящее время системных последовательностей нет, поэтому это представление всегда пусто.)
pg_statio_user_sequences	Аналогично pg_statio_all_sequences , за исключением того, что показываются только пользовательские последовательности.
pg_stat_user_functions	По одной строке для каждой отслеживаемой функции со статистикой по выполнениям этой функции. Более подробно смотрите pg_stat_user_functions.
pg_stat_xact_user_functions	Аналогично pg_stat_user_functions , однако подсчитываются только вызовы функций, выполненные в текущей транзакции (которые ещё не были включены в pg_stat_user_functions ).

Статистика по отдельным индексам особенно полезна для определения того, какие индексы используются и насколько они эффективны.

Представления pg_statio_ полезны, прежде всего, для определения эффективности буферного кеша. Если количество фактических дисковых чтений существенно меньше количества чтений из буферного кеша, то это означает, что кеш справляется с большинством запросов на чтение без обращения к ядру. Однако эта статистика не даёт полной картины: PostgreSQL обрабатывает дисковый ввод/вывод так, что данные, не находящиеся в буферном кеше PostgreSQL , могут все ещё располагаться в кеше ввода/вывода ядра, и, следовательно, для их получения физическое чтение может не использоваться. Для получения более детальной информации о процессе ввода/вывода в PostgreSQL рекомендуется использовать сборщик статистики PostgreSQL в сочетании с утилитами операционной системы, которые дают более полное представление о том, как ядро осуществляет ввод/вывод.

Таблица 28.3. Представление pg_stat_activity

Столбец	Тип	Описание
datid	oid	OID базы данных, к которой подключён этот серверный процесс
datname	name	Имя базы данных, к которой подключён этот серверный процесс
pid	integer	Идентификатор процесса этого серверного процесса
usesysid	oid	OID пользователя, подключённого к этому серверному процессу
usename	name	Имя пользователя, подключённого к этому серверному процессу
application_name	text	Название приложения, подключённого к этому серверному процессу
client_addr	inet	IP-адрес клиента, подключённого к этому серверному процессу. Значение null в этом поле означает, что клиент подключён через сокет Unix на стороне сервера или что это внутренний процесс, например, автоочистка.
client_hostname	text	Имя компьютера для подключённого клиента, получаемое в результате обратного поиска в DNS по client_addr . Это поле будет отлично от null только в случае соединений по IP и только при включённом режиме log_hostname.
client_port	integer	Номер TCP-порта, который используется клиентом для соединения с этим серверным процессом, или -1 , если используется сокет Unix
backend_start	timestamp with time zone	Время запуска процесса, т. е. время, когда клиент подсоединился к серверу
xact_start	timestamp with time zone	Время начала текущей транзакции в этом процессе или null при отсутствии активной транзакции. Если текущий запрос был первым в своей транзакции, то значение в этом столбце совпадает со значением столбца query_start .
query_start	timestamp with time zone	Время начала выполнения активного в данный момент запроса, или, если state не active , то время начала выполнения последнего запроса
state_change	timestamp with time zone	Время последнего изменения состояния (поля state )
wait_event_type	text	Тип события, которого ждёт обслуживающий процесс, если это имеет место; в противном случае — NULL. Возможные значения:

LWLockNamed : Обслуживающий процесс ожидает определённую именованную лёгкую блокировку. Такие блокировки защищают определённые структуры данных в разделяемой памяти. Имя блокировки будет показывается в wait_event .

LWLockTranche : Обслуживающий процесс ожидает одну из группы связанных лёгких блокировок. Все блокировки в этой группе выполняют схожие функции; общее предназначение блокировок в этой группе показывается в wait_event .

Lock : Обслуживающий процесс ожидает тяжёлую блокировку. Тяжёлые блокировки, также называемые блокировками менеджера блокировок или просто блокировками, в основном защищают объекты уровня SQL, такие как таблицы. Однако они также применяются для взаимоисключающего выполнения некоторых внутренних операций, например, для расширения отношений. Тип ожидаемой блокировки показывается в wait_event .

active : серверный процесс выполняет запрос.

idle : серверный процесс ожидает новой команды от клиента.

idle in transaction : серверный процесс находится внутри транзакции, но в настоящее время не выполняет никакой запрос.

idle in transaction (aborted) : Это состояние подобно idle in transaction , за исключением того, что один из операторов в транзакции вызывал ошибку.

fastpath function call : серверный процесс выполняет fast-path функцию.

В представлении pg_stat_activity для каждого серверного процесса будет присутствовать по одной строке с информацией, относящейся к текущей деятельности этого процесса.

Примечание

Значения в столбцах wait_event и state не зависят друг от друга. Если обслуживающий процесс находится в состоянии active (активен), он может ожидать какое-то событие, или не ожидать никакое. Если состояние active и поле wait_event содержит не NULL, это означает, что запрос выполняется, но заблокирован чем-то в системе.

Таблица 28.4. Описание wait_event

Тип события ожидания	Название события ожидания	Описание
LWLockNamed	ShmemIndexLock	Ожидание при поиске или выделении области в разделяемой памяти.
	OidGenLock	Ожидание при выделении или назначении OID.
	XidGenLock	Ожидание при выделении или назначении идентификатора транзакции.
	ProcArrayLock	Ожидание при получении снимка или очистке идентификатора транзакции в конце транзакции.
	SInvalReadLock	Ожидание при получении или удалении из общей очереди сообщений аннулирования.
	SInvalWriteLock	Ожидание при добавлении в общую очередь сообщения аннулирования.
	WALBufMappingLock	Ожидание при замене страницы в буферах WAL.
	WALWriteLock	Ожидание при записи буферов WAL на диск.
	ControlFileLock	Ожидание при чтении или изменении управляющего файла либо при создании нового файла WAL.
	CheckpointLock	Ожидание при выполнении контрольной точки.
	CLogControlLock	Ожидание при чтении или изменении состояния транзакции.
	SubtransControlLock	Ожидание при чтении или изменении информации о подтранзакции.
	MultiXactGenLock	Ожидание при чтении или изменении общего состояния мультитранзакций.
	MultiXactOffsetControlLock	Ожидание при чтении или изменении смещений мультитранзакций.
	MultiXactMemberControlLock	Ожидание при чтении или изменении членов мультитранзакций.
	RelCacheInitLock	Ожидание при чтении или записи файла инициализации кеша отношения.
	CheckpointerCommLock	Ожидание при управлении запросами fsync.
	TwoPhaseStateLock	Ожидание при чтении или изменении состояния подготовленных транзакций.
	TablespaceCreateLock	Ожидание при создании или удалении табличного пространства.
	BtreeVacuumLock	Ожидание при чтении или изменении информации, связанной с очисткой, для индекса-B-дерева.
	AddinShmemInitLock	Ожидание при управлении выделением блоков в общей памяти.
	AutovacuumLock	Ожидание в рабочем процессе или процедуре запуска автоочистки при изменении или чтении текущего состояния рабочих процессов автоочистки.
	AutovacuumScheduleLock	Ожидание при подтверждении, что таблица, выбранная для очистки, всё ещё нуждается в очистке.
	SyncScanLock	Ожидание при получении начального положения сканирования таблицы для синхронизированного сканирования.
	RelationMappingLock	Ожидание при изменении в файле сопоставления отношений, используемого для хранения связей файловых узлов с каталогом БД.
	AsyncCtlLock	Ожидание при чтении или изменении общего состояния уведомлений.
	AsyncQueueLock	Ожидание при чтении или изменении сообщений уведомлений.
	SerializableXactHashLock	Ожидание при получении или сохранении информации о сериализуемых транзакциях.
	SerializableFinishedListLock	Ожидание при обращении к списку завершённых сериализуемых транзакций.
	SerializablePredicateLockListLock	Ожидание при выполнении операции со списком блокировок, удерживаемых сериализуемыми транзакциями.
	OldSerXidLock	Ожидание при чтении или записи информации о конфликтующих сериализуемых транзакциях.
	SyncRepLock	Ожидание при чтении или изменении сведений о синхронных репликах.
	BackgroundWorkerLock	Ожидание при чтении или изменении состояния фонового рабочего процесса.
	DynamicSharedMemoryControlLock	Ожидание при чтении или изменении состояния динамической общей памяти.
	AutoFileLock	Ожидание при изменении файла postgresql.auto.conf .
	ReplicationSlotAllocationLock	Ожидание при выделении или освобождении слота репликации.
	ReplicationSlotControlLock	Ожидание при чтении или изменении состояния слота репликации.
	CommitTsControlLock	Ожидание при чтении или изменении времени фиксирования транзакции.
	CommitTsLock	Ожидание при чтении или изменении последнего значения, заданного в качестве времени транзакции.
	ReplicationOriginLock	Ожидание при подготовке, удалении или использовании источника репликации.
	MultiXactTruncationLock	Ожидание при чтении или очистке информации мультитранзакций.
	OldSnapshotTimeMapLock	Ожидание при чтении или изменении информации о старом снимке.
	WrapLimitsVacuumLock	Ожидание при изменении лимитов идентификаторов транзакций и мультитранзакций.
	NotifyQueueTailLock	Ожидание при изменении границы массива с сообщениями уведомлений.
LWLockTranche	clog	Ожидание при вводе/выводе с буфером clog (буфер состояния транзакций).
	commit_timestamp	Ожидание при вводе/выводе с буфером времени фиксирования транзакций.
	subtrans	Ожидание при вводе/выводе с буфером подтранзакций.
	multixact_offset	Ожидание при вводе/выводе с буфером смещений мультитранзакций.
	multixact_member	Ожидание при вводе/выводе с буфером multixact_member.
	async	Ожидание при вводе/выводе с буфером асинхронных сообщений (уведомлений).
	oldserxid	Ожидание при вводе/выводе с буфером oldserxid.
	wal_insert	Ожидание при добавлении записей WAL в буфер в памяти.
	buffer_content	Ожидание при чтении или записи страницы данных в памяти.
	buffer_io	Ожидание при вводе/выводе, связанном со страницей данных.
	replication_origin	Ожидание при чтении или изменении состояния репликации.
	replication_slot_io	Ожидание при вводе/выводе со слотом репликации.
	proc	Ожидание при чтении или изменении информации о блокировках по быстрому пути.
	buffer_mapping	Ожидание при связывании блока данных с буфером в пуле буферов.
	lock_manager	Ожидание при добавлении или обращении к блокировкам обслуживающих процессов либо ожидание входа или выхода из группы блокировок (используется в параллельных запросах).
	predicate_lock_manager	Ожидание при добавлении или обращении к информации о предикатных блокировках.
Lock	relation	Ожидание при запросе блокировки для отношения.
	extend	Ожидание при расширении отношения.
	frozenid	Ожидание изменения pg_database . datfrozenxid и pg_database . datminmxid .
	page	Ожидание при запросе блокировки для страницы отношения.
	tuple	Ожидание при запросе блокировки для кортежа.
	transactionid	Ожидание завершения транзакции.
	virtualxid	Ожидание при запросе блокировки виртуального xid.
	speculative token	Ожидание при запросе блокировки спекулятивного добавления.
	object	Ожидание при запросе блокировки для нереляционного объекта БД.
	userlock	Ожидание при запросе пользовательской блокировки.
	advisory	Ожидание при запросе рекомендательной пользовательской блокировки.
BufferPin	BufferPin	Ожидание при закреплении буфера.

Примечание

Для траншей, регистрируемых расширениями, в поле wait_event выводится имя, указываемое расширением. Пользователь вполне может зарегистрировать транш и в обслуживающем процессе (воспользовавшись динамической общей памятью), в результате чего другие процессы не получат доступа к этой информации; в таких случаях в этом поле выводится extension .

Следующая команда показывает, как можно просмотреть события ожидания:

SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event is NOT NULL; pid | wait_event_type | wait_event ------+-----------------+--------------- 2540 | Lock | relation 6644 | LWLockNamed | ProcArrayLock (2 rows)

Таблица 28.5. Представление pg_stat_replication

Столбец	Тип	Описание
pid	integer	Идентификатор процесса-передатчика WAL
usesysid	oid	OID пользователя, подключённого к этому процессу-передатчику WAL
usename	name	Имя пользователя, подключённого к этому процессу-передатчику WAL
application_name	text	Имя приложения, которое подключено к этому процессу-передатчику WAL
client_addr	inet	IP-адрес клиента, подключённого к этому процессу-передатчику WAL. Значение null в этом поле говорит о том, что клиент подсоединён через сокет Unix на сервере.
client_hostname	text	Имя компьютера для подключённого клиента, получаемое в результате обратного поиска в DNS по client_addr . Это поле будет отлично от null только в случае соединений по IP и только при включённом режиме log_hostname.
client_port	integer	Номер TCP-порта, который используется клиентом для взаимодействия с процессом-передатчиком WAL, или -1 , если используется сокет Unix
backend_start	timestamp with time zone	Время запуска процесса, т. е. время подключения клиента к этому процессу-передатчику WAL
backend_xmin	xid	Значение xmin , полученное от ведомого сервера при включённом hot_standby_feedback.
state	text	Текущее состояние процесса-передатчика WAL
sent_location	pg_lsn	Позиция последней транзакции в журнале транзакций, отправленной по этому соединению
write_location	pg_lsn	Позиция последней транзакции в журнале транзакций, записанной на диск ведомым сервером
flush_location	pg_lsn	Позиция последней транзакции в журнале транзакций, сброшенной на диск ведомым сервером
replay_location	pg_lsn	Позиция последней транзакции в журнале транзакций, выполненной в этой базе данных на ведомом сервере
sync_priority	integer	Приоритет этого ведомого сервера для выбора в качестве синхронного ведомого
sync_state	text	Состояние синхронизации для этого ведомого сервера

Представление pg_stat_replication для каждого процесса-передатчика WAL будет содержать по одной строке со статистикой о репликации на ведомый сервер, к которому подключён этот процесс. В представлении перечисляются только ведомые серверы, подключённые напрямую; информация о ведомых серверах, подключённых опосредованно, не представлена.

Таблица 28.6. Представление pg_stat_wal_receiver

Столбец	Тип	Описание
pid	integer	Идентификатор процесса WAL-приёмника
status	text	Состояние активности процесса WAL-приёмника
receive_start_lsn	pg_lsn	Первая позиция в журнале транзакции в момент запуска приёмника WAL
receive_start_tli	integer	Первый номер линии времени в момент запуска приёмника WAL
received_lsn	pg_lsn	Последняя позиция в журнале транзакций, уже полученная и сброшенная на диск; начальным значением этого поля будет первая позиция в журнале в момент запуска приёмника WAL
received_tli	integer	Номер линии времени последней позиции в журнале транзакции, уже полученной и сброшенной на диск; начальным значением этого поля будет линия времени первой позиции в момент запуска приёмника WAL
last_msg_send_time	timestamp with time zone	Время отправки последнего сообщения, полученного от изначального передатчика WAL
last_msg_receipt_time	timestamp with time zone	Время поступления последнего сообщения, полученного от изначального передатчика WAL
latest_end_lsn	pg_lsn	Последняя позиция в журнале транзакций, сообщённая изначальному передатчику WAL
latest_end_time	timestamp with time zone	Время, когда последняя позиция в журнале транзакций была сообщена изначальному передатчику WAL
slot_name	text	Имя слота репликации, используемого этим приёмником WAL
conninfo	text	Строка подключения, используемая этим приёмником WAL (секретные поля в ней скрыты).

Представление pg_stat_wal_receiver будет иметь только одну строку со статистикой приёмника WAL от сервера, на котором работает приёмник.

Таблица 28.7. Представление pg_stat_ssl

Столбец	Тип	Описание
pid	integer	Идентификатор обслуживающего процесса или процесса, передающего WAL
ssl	boolean	True, если для этого подключения используется SSL
version	text	Версия SSL либо NULL, если SSL для этого подключения не используется
cipher	text	Имя применяемого шифра SSL либо NULL, если SSL для этого подключения не используется
bits	integer	Число бит в применяемом алгоритме шифрования либо NULL, если SSL для этого подключения не используется
compression	boolean	True, если применяется сжатие SSL, false в противном случае, либо NULL, если SSL для этого подключения не используется
clientdn	text	Поле DN (Distinguished Name, Уникальное имя) из используемого клиентского сертификата либо NULL, если клиент не передал сертификат или SSL для этого подключения не используется. Это значение усекается, если поле DN оказывается длиннее NAMEDATALEN символов (64 символа в стандартной сборке)

Представление pg_stat_ssl содержит по одной строке для каждого обслуживающего процесса и процесса, передающего WAL, и показывает статистику использования SSL для подключений. Его можно соединить с pg_stat_activity или pg_stat_replication по столбцу pid и получить дополнительные сведения о подключении.

Таблица 28.8. Представление pg_stat_archiver

Столбец	Тип	Описание
archived_count	bigint	Число файлов WAL, которые были успешно архивированы
last_archived_wal	text	Имя последнего файла WAL успешно архивированного
last_archived_time	timestamp with time zone	Время последней успешной архивации
failed_count	bigint	Число неудачных попыток архивации файлов WAL
last_failed_wal	text	Имя файла WAL последней неудавшейся архивации
last_failed_time	timestamp with time zone	Время последней неудавшейся архивации
stats_reset	timestamp with time zone	Последнее время сброса этих статистических данных

В представлении pg_stat_archiver всегда будет одна строка, содержащая данные о текущем состоянии процесса архивации в кластере.

Таблица 28.9. Представление pg_stat_bgwriter

Столбец	Тип	Описание
checkpoints_timed	bigint	Количество запланированных контрольных точек, которые уже были выполнены
checkpoints_req	bigint	Количество запрошенных контрольных точек, которые уже были выполнены
checkpoint_write_time	double precision	Общее время, которое было затрачено на этап обработки контрольной точки, в котором файлы записываются на диск, в миллисекундах
checkpoint_sync_time	double precision	Общее время, которое было затрачено на этап обработки контрольной точки, в котором файлы синхронизируются с диском, в миллисекундах
buffers_checkpoint	bigint	Количество буферов, записанных при выполнении контрольных точек
buffers_clean	bigint	Количество буферов, записанных фоновым процессом записи
maxwritten_clean	bigint	Сколько раз фоновый процесс записи останавливал сброс грязных страниц на диск из-за того, что записал слишком много буферов
buffers_backend	bigint	Количество буферов, записанных самим серверным процессом
buffers_backend_fsync	bigint	Сколько раз серверному процессу пришлось выполнить fsync самостоятельно (обычно фоновый процесс записи сам обрабатывает эти вызовы, даже когда серверный процесс выполняет запись самостоятельно)
buffers_alloc	bigint	Количество выделенных буферов
stats_reset	timestamp with time zone	Последнее время сброса этих статистических данных

В представлении pg_stat_bgwriter всегда будет только одна строка, в которой будут представлены общие данные по всему кластеру.

Таблица 28.10. Представление pg_stat_database

Столбец	Тип	Описание
datid	oid	OID базы данных
datname	name	Имя базы данных
numbackends	integer	Количество серверных процессов, в настоящее время подключённых к этой базе данных. Это единственный столбец в этом представлении, значение в котором отражает текущее состояние; все другие столбцы возвращают суммарные значения со времени последнего сброса статистики.
xact_commit	bigint	Количество зафиксированных транзакций в этой базе данных
xact_rollback	bigint	Количество транзакций в этой базе данных, для которых был выполнен откат транзакции
blks_read	bigint	Количество прочитанных дисковых блоков в этой базе данных
blks_hit	bigint	Сколько раз дисковые блоки обнаруживались в буферном кеше, так что чтение с диска не потребовалось (в значение входят только случаи обнаружения в буферном кеше PostgreSQL, а не в кеше файловой системы ОС)
tup_returned	bigint	Количество строк, возвращённое запросами в этой базе данных
tup_fetched	bigint	Количество строк, извлечённое запросами в этой базе данных
tup_inserted	bigint	Количество строк, вставленное запросами в этой базе данных
tup_updated	bigint	Количество строк, изменённое запросами в этой базе данных
tup_deleted	bigint	Количество строк, удалённое запросами в этой базе данных
conflicts	bigint	Количество запросов, отменённых из-за конфликта с восстановлением в этой базе данных. (Конфликты происходят только на ведомых серверах; более подробно смотрите pg_stat_database_conflicts.)
temp_files	bigint	Количество временных файлов, созданных запросами в этой базе данных. Подсчитываются все временные файлы независимо от причины их создания (например, для сортировки или для хеширования) и независимо от установленного значения log_temp_files
temp_bytes	bigint	Общий объём данных, записанных во временные файлы запросами в этой базе данных. Учитываются все временные файлы, вне зависимости от того, по какой причине они созданы и вне зависимости от значения log_temp_files.
deadlocks	bigint	Количество взаимных блокировок, зафиксированное в этой базе данных
blk_read_time	double precision	Время, затраченное серверными процессами в этой базе данных, на чтение блоков из файлов данных, в миллисекундах
blk_write_time	double precision	Время, затраченное серверными процессами в этой базе данных, на запись блоков в файлы данных, в миллисекундах
stats_reset	timestamp with time zone	Последнее время сброса этих статистических данных

Представление pg_stat_database содержит одну строку со статистикой на каждую базу данных кластера.

Таблица 28.11. Представление pg_stat_database_conflicts

Столбец	Тип	Описание
datid	oid	OID базы данных
datname	name	Имя базы данных
confl_tablespace	bigint	Количество запросов в этой базе данных, отменённых из-за того, что табличные пространства были удалены
confl_lock	bigint	Количество запросов в этой базе данных, отменённых по истечении времени ожидания блокировки
confl_snapshot	bigint	Количество запросов в этой базе данных, отменённых из-за устаревших снимков данных
confl_bufferpin	bigint	Количество запросов в этой базе данных, отменённых из-за прикреплённых страниц буфера
confl_deadlock	bigint	Количество запросов в этой базе данных, отменённых из-за взаимных блокировок

Представление pg_stat_database_conflicts для каждой базы данных будет содержать по одной строке со статистикой на уровне базы по отменам запросов, произошедшим вследствие конфликтов с процессами восстановления на ведомых серверах. В этом представлении будет содержаться только информация по ведомым серверам, поскольку на главных серверах конфликты не возникают.

Таблица 28.12. Представление pg_stat_all_tables

Столбец	Тип	Описание
relid	oid	OID таблицы
schemaname	name	Имя схемы, в которой расположена эта таблица
relname	name	Имя таблицы
seq_scan	bigint	Количество последовательных чтений, произведённых в этой таблице
seq_tup_read	bigint	Количество «живых» строк, прочитанных при последовательных чтениях
idx_scan	bigint	Количество сканирований по индексу, произведённых в этой таблице
idx_tup_fetch	bigint	Количество «живых» строк, отобранных при сканированиях по индексу
n_tup_ins	bigint	Количество вставленных строк
n_tup_upd	bigint	Количество изменённых строк (включая изменения по схеме HOT)
n_tup_del	bigint	Количество удалённых строк
n_tup_hot_upd	bigint	Количество строк, обновлённых в режиме HOT (т. е. без отдельного изменения индекса)
n_live_tup	bigint	Оценочное количество «живых» строк
n_dead_tup	bigint	Оценочное количество «мёртвых» строк
n_mod_since_analyze	bigint	Оценочное число строк, изменённых в этой таблице с момента последнего сбора статистики
last_vacuum	timestamp with time zone	Время последней очистки этой таблицы вручную ( VACUUM FULL не учитывается)
last_autovacuum	timestamp with time zone	Время последней очистки таблицы фоновым процессом автоочистки
last_analyze	timestamp with time zone	Время последнего выполнения сбора статистики для этой таблицы вручную
last_autoanalyze	timestamp with time zone	Время последнего выполнения сбора статистики для этой таблицы фоновым процессом автоочистки
vacuum_count	bigint	Сколько раз очистка этой таблицы была выполнена вручную ( VACUUM FULL не учитывается)
autovacuum_count	bigint	Сколько раз очистка этой таблицы была выполнена фоновым процессом автоочистки
analyze_count	bigint	Сколько раз сбор статистики для этой таблицы был выполнен вручную
autoanalyze_count	bigint	Сколько раз сбор статистики для этой таблицы был выполнен фоновым процессом автоочистки

Представление pg_stat_all_tables будет содержать по одной строке на каждую таблицу в текущей базе данных (включая таблицы TOAST) со статистикой по обращениям к этой таблице. Представления pg_stat_user_tables и pg_stat_sys_tables содержат ту же самую информацию, но отфильтрованную так, чтобы показывать только пользовательские и системные таблицы соответственно.

Таблица 28.13. Представление pg_stat_all_indexes

Столбец	Тип	Описание
relid	oid	OID таблицы для индекса
indexrelid	oid	OID индекса
schemaname	name	Имя схемы, в которой расположен индекс
relname	name	Имя таблицы для индекса
indexrelname	name	Имя индекса
idx_scan	bigint	Количество произведённых сканирований по этому индексу
idx_tup_read	bigint	Количество элементов индекса, возвращённых при сканированиях по этому индексу
idx_tup_fetch	bigint	Количество живых строк таблицы, отобранных при простых сканированиях по этому индексу

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

Индексы могут использоваться при простом сканировании по индексу, при сканировании « битовой карты » индекса и в работе оптимизатора. Результаты сканирования битовых карт разных индексов могут объединяться логическим умножением или сложением, поэтому когда применяются битовые карты, сложно связать выборки отдельных строк с определёнными индексами. Поэтому при сканировании битовых карт увеличиваются счётчики pg_stat_all_indexes . idx_tup_read для задействованных индексов и счётчик pg_stat_all_tables . idx_tup_fetch для каждой таблицы, а pg_stat_all_indexes . idx_tup_fetch не меняется. Оптимизатор тоже обращается к индексам для проверки переданных констант, значения которых оказываются вне диапазона, записанного в статистике оптимизатора, так как эта статистика может быть неактуальной.

Примечание

Значения счётчиков idx_tup_read и idx_tup_fetch могут различаться, даже если сканирование с использованием битовой карты не используется, поскольку idx_tup_read подсчитывает полученные из индекса элементы, а idx_tup_fetch — количество «живых» строк, выбранных из таблицы. Различие будет меньше, если «мёртвые» или ещё не зафиксированные строки будут извлекаться с использованием индекса или если для получения строк таблицы будет использоваться сканирование только по индексу.

Таблица 28.14. Представление pg_statio_all_tables

Столбец	Тип	Описание
relid	oid	OID таблицы
schemaname	name	Имя схемы, в которой расположена эта таблица
relname	name	Имя таблицы
heap_blks_read	bigint	Количество дисковых блоков, прочитанных из этой таблицы
heap_blks_hit	bigint	Число попаданий в буфер для этой таблицы
idx_blks_read	bigint	Количество дисковых блоков, прочитанных из всех индексов этой таблицы
idx_blks_hit	bigint	Число попаданий в буфер для всех индексов по этой таблице
toast_blks_read	bigint	Количество прочитанных дисковых блоков TOAST (если есть) для этой таблицы
toast_blks_hit	bigint	Число попаданий в буфер в таблице TOAST для этой таблицы (если такие есть)
tidx_blks_read	bigint	Количество прочитанных дисковых блоков из индекса по TOAST (если есть) для этой таблицы
tidx_blks_hit	bigint	Число попаданий в буфер для индекса по TOAST (если есть) для этой таблицы

Представление pg_statio_all_tables для каждой таблицы (включая таблицы TOAST) в текущей базе данных будет содержать по одной строке со статистикой по операциям ввода/вывода для этой таблицы. Представления pg_statio_user_tables и pg_statio_sys_tables содержат ту же самую информацию, но отфильтрованную так, чтобы показывать только пользовательские или системные таблицы соответственно.

Таблица 28.15. Представление pg_statio_all_indexes

Столбец	Тип	Описание
relid	oid	OID таблицы для индекса
indexrelid	oid	OID индекса
schemaname	name	Имя схемы, в которой расположен индекс
relname	name	Имя таблицы для индекса
indexrelname	name	Имя индекса
idx_blks_read	bigint	Количество дисковых блоков, прочитанных из этого индекса
idx_blks_hit	bigint	Число попаданий в буфер для этого индекса

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

Таблица 28.16. Представление pg_statio_all_sequences

Столбец	Тип	Описание
relid	oid	OID последовательности
schemaname	name	Имя схемы, в которой расположена эта последовательность
relname	name	Имя последовательности
blks_read	bigint	Количество дисковых блоков, прочитанных из этой последовательности
blks_hit	bigint	Число попаданий в буфер в этой последовательности

Представление pg_statio_all_sequences для каждой последовательности в текущей базе данных будет содержать по одной строке со статистикой по операциям ввода/вывода для этой последовательности.

Таблица 28.17. Представление pg_stat_user_functions

Столбец	Тип	Описание
funcid	oid	OID функции
schemaname	name	Имя схемы, в которой расположена функция
funcname	name	Имя функции
calls	bigint	Сколько раз вызывалась функция
total_time	double precision	Общее время, потраченное на выполнение этой функции и всех других функций, вызванных ею, в миллисекундах
self_time	double precision	Общее время, потраченное на выполнение самой функции, без учёта других функций, которые были ею вызваны, в миллисекундах

Представление pg_stat_user_functions для каждой отслеживаемой функции будет содержать по одной строке со статистикой по выполнениям этой функции. Отслеживаемые функции определяются параметром track_functions.

28.2.3. Статистические функции

Статистическую информацию можно просматривать и другими способами. Для этого можно написать запросы, использующие те же функции доступа к статистике, что лежат в основе описанных выше стандартных представлений. За более подробной информацией, например, об именах этих функций, обратитесь к определениям этих стандартных представлений. (Например, в psql можно выполнить \d+ pg_stat_activity .) В качестве аргумента функции, предоставляющие доступ к статистике на уровне базы, принимают OID базы данных, по которой должна быть выдана информация. Функции, которые работают на уровне таблиц и индексов, принимают в качестве аргумента OID таблицы или индекса. Аргументом для функции, предоставляющей статистику на уровне функций, является OID функции. Обратите внимание, что с помощью этих функций можно получить информацию по таблицам, индексам и функциям исключительно в текущей базе данных.

Дополнительные функции, связанные со сбором статистики, перечислены в Таблице 28.18.

Таблица 28.18. Дополнительные статистические функции

Функция	Тип результата	Описание
pg_backend_pid()	integer	Идентификатор серверного процесса, выполняющего текущую сессию
pg_stat_get_activity ( integer )	setof record	Возвращает запись с информацией о серверном процессе с заданным PID или по одной строке для каждого активного серверного процесса в системе, если был указан NULL . Возвращаемые поля являются подмножеством столбцов представления pg_stat_activity .
pg_stat_get_snapshot_timestamp()	timestamp with time zone	Возвращает время снимка текущей статистики
pg_stat_clear_snapshot()	void	Сбросить текущий снимок статистики
pg_stat_reset()	void	Сбросить в ноль все статистические счётчики в текущей базе данных (по умолчанию разрешено только суперпользователям, но право выполнения (EXECUTE) этой функции можно дать и другим)
pg_stat_reset_shared (text)	void	Сбросить в ноль некоторые статистические счётчики на уровне кластера, в зависимости от заданного аргумента (по умолчанию разрешено только суперпользователям, но право выполнения (EXECUTE) этой функции можно дать и другим). Вызов pg_stat_reset_shared('bgwriter') сбросит в ноль все счётчики, которые показываются в представлении pg_stat_bgwriter , а вызов pg_stat_reset_shared('archiver') — все счётчики в представлении pg_stat_archiver .
pg_stat_reset_single_table_counters (oid)	void	Сбросить в ноль статистику по отдельной таблице или индексу в текущей базе данных (по умолчанию разрешено только суперпользователям, но право выполнения (EXECUTE) этой функции можно дать и другим)
pg_stat_reset_single_function_counters (oid)	void	Сбросить в ноль статистику по отдельной функции в текущей базе данных (по умолчанию разрешено только суперпользователям, но право выполнения (EXECUTE) этой функции можно дать и другим)

Функция pg_stat_get_activity , на которой основано представление pg_stat_activity , возвращает набор строк, содержащих всю доступную информацию о каждом серверном процессе. Иногда более удобным оказывается получение только части этой информации. В таких случаях можно использовать набор более старых функций, дающих доступ к статистике на уровне серверных процессов; эти функции описаны в Таблице 28.19. Эти функции используют идентификатор серверного процесса, значение которого варьируется от единицы до числа активных в настоящий момент серверных процессов. Функция pg_stat_get_backend_idset генерирует по одной строке для каждого активного серверного процесса, что необходимо для вызова этих функций. Например, для того, чтобы отобразить значения PID и текущие запросы всех серверных процессов:

SELECT pg_stat_get_backend_pid(s.backendid) AS pid, pg_stat_get_backend_activity(s.backendid) AS query FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;

Таблица 28.19. Статистические функции на уровне серверных процессов

Функция	Тип результата	Описание
pg_stat_get_backend_idset()	setof integer	Набор значений идентификаторов активных в настоящий момент серверных процессов (от 1 до числа активных серверных процессов)
pg_stat_get_backend_activity(integer)	text	Текст последнего запроса этого серверного процесса
pg_stat_get_backend_activity_start(integer)	timestamp with time zone	Время запуска последнего запроса
pg_stat_get_backend_client_addr(integer)	inet	IP-адрес клиента, подключённого к этому серверному процессу
pg_stat_get_backend_client_port(integer)	integer	Номер TCP-порта, который клиент использует для взаимодействия
pg_stat_get_backend_dbid(integer)	oid	OID базы данных, к которой подключён этот серверный процесс
pg_stat_get_backend_pid(integer)	integer	Идентификатор процесса этого серверного процесса
pg_stat_get_backend_start(integer)	timestamp with time zone	Время запуска этого процесса
pg_stat_get_backend_userid(integer)	oid	OID пользователя, подключённого к этому серверному процессу
pg_stat_get_backend_wait_event_type(integer)	text	Имя типа ожидаемого события, если обслуживающий процесс находится в состоянии ожидания, а в противном случае — NULL. За подробностями обратитесь к Таблице 28.4.
pg_stat_get_backend_wait_event(integer)	text	Имя ожидаемого события, если обслуживающий процесс находится в состоянии ожидания, а в противном случае — NULL. За подробностями обратитесь к Таблице 28.4.
pg_stat_get_backend_xact_start(integer)	timestamp with time zone	Время начала текущей транзакции

Пред.	Наверх	След.
28.1. Стандартные инструменты Unix	Начало	28.3. Просмотр информации о блокировках

Немного о конфигурировании PostgreSQL

Я много работал с PostgreSQL и считаю его прекрасной СУБД. У меня многогигабайтная рабочая база (не 1С) обрабатывает моментально огромные массивы данных. PostgreSQL прекрасно использует индексы, хорошо справляется с параллельной нагрузкой, функционал хранимых процедур на высоте, есть хорошие средства администрирования и повышения производительности "из коробки", а сообщество создало полезные утилиты. Но я с удивлением узнал что у многих администраторов 1С мнение о PostgreSQL не на высоте, что он тормоз и едва обгоняет файловый вариант базы, и только MSSQL может спасти положение.

Поизучав вопрос, я нашел множество статей по установке PostgreSQL по шагам для чайников, как по Linux, так и под Windows. Но подавляющее большинство статей описывают установку до "установилось - создадим базу", и совершенно не затрагивают вопрос конфигурирования. В оставшихся конфигурирование упоминается лишь на уровне "прописать такие значения", практически не объясняя зачем.

И если подход "установка в одну кнопку" применим к MSSQL и вообще многим продуктам под Windows, то к PostgreSQL он, к сожалению, не относится. Настройки по умолчанию очень сильно ограничивают его в использовании памяти, чтобы можно было его установить хоть на калькулятор и он там не мешал работе остального ПО. PostgreSQL обязательно нужно конфигурировать под конкретную систему, и только тогда он сможет показать себя на высоте. В особо тяжелых случаях можно тюнинговать настройки PostgreSQL, базы и файловой системы друг под друга, но это касается в большей степени Linux-систем, где больше возможностей по настройке всего и вся.

Следует напомнить, что для 1С не подойдет сборка PostgreSQL от разработчиков СУБД, только собранная из пропатченных 1С исходных текстов. Готовые совместимые сборки предлагает 1С (через диски ИТС и кабинет для имеющих подписку на поддержку) и EterSoft Тестирование и сравнение

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

Для тестирования я использовал следующую конфигурацию:
Host-машина: Win7, Core i5-760 2.8MHz, 4 ядра, 12Гб ОЗУ, VMWare 10
Виртуальная: Win7 x64, 2 ядра, 4Гб ОЗУ, отдельный физический жесткий диск для размещения БД (не SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383

Использовалась БД, dt-выгрузка 780Мб.
После восстановления базы:
размер файла 1CD в файловом варианте - 10Гб,
размер базы PostgreSQL - 8Гб,
размер базы MSSQL - 6.7Гб.

Для теста использовал запрос на выборку договоров контрагентов (21к) с выборкой дополнительных реквизитов из различных регистров, для каждого договора фактически делалась отдельная выборка из регистров. Конфигурацию взял что была под рукой - сильно доработанная на базе Бухгалтерии 3.0.

При тестировании выполнял запрос одним и двумя клиентами по несколько раз до получения стабильных результатов. Первые прогоны игнорировал.

Тестирование одним клиентом:

Выборка на хосте из файлового варианта с размещением базы на SSD - 31с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - 46с
Выборка из MSSQL-базы - первый проход - 25с или 9с (видимо в зависимости от актуальности кэша СУБД) (потребление памяти процессом СУБД составило примерно 1.3Гб)
Выборка из PostgreSQL с настройками по умолчанию - 43с (потребление памяти не превышало 80Мб на подключение)
Выборка из оптимизированного PostgreSQL - 21с (потребление памяти составило 120Мб на подключение)

Тестирование двумя клиентами:

Выборка на хосте из файлового варианта с размещением базы на SSD - по 34с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - по 56с
Выборка из MSSQL-базы - по 50с или 20с (видимо в зависимости от актуальности кэша СУБД)
Выборка из PostgreSQL с настройками по умолчанию - по 60с
Выборка из оптимизированного PostgreSQL - по 40с

Замечания к тестированию:

1. После добавления третьего ядра PostgreSQL и MSSQL-варианты стали работать в тесте "два клиента" практически с производительностью теста "один клиент", т.е. удачно распараллелились. Что мешало им параллелить работу на двух ядрах для меня осталось загадкой.
2. MSSQL памяти захватил сразу много, PostgreSQL требовал во всех режимах существенно меньше, и сразу после завершения выполнения запроса почти всю высвобождал.
3. MSSQL работает единым процессом. PostgreSQL запускает по отдельному процессу на подключение+служебные процессы. Это позволяет даже 32-разрядному варианту эффективно использовать память при обработке запросов от нескольких клиентов.
4. Увеличение памяти для PostgreSQL в настройках свыше указанных ниже значений не привело к заметному росту производительности.
5. Первые тесты во всех случаях проходили дольше чем в последующих замерах, специально замеры не производил, но MSSQL субъективно стартовал быстрее.

Конфигурирование PostgreSQL

Есть прекрасная книга на русском языке о конфигурировании и оптимизировании PostgreSQL: host all all 127.0.0.1/32 trust

И подключаться любым пользователем (например, postgres) к СУБД на локальной машине по адресу 127.0.0.1 без проверки пароля.

Оптимизация использования памяти

Настройки использования памяти располагаются в postgresql.conf

Оптимальные значения параметров зависят от объема свободной оперативной памяти, размера базы и отдельных элементов базы (таблицы и индексы), сложности запросов (в принципе, стоит полагаться что запросы будут достаточно сложными - множественные соединения в запросах это типовой сценарий) и количества одновременных активных клиентов. Кстати, PostgreSQL хранит таблицы и индексы БД в отдельных файлах (\data\base\\), и размеры объектов можно оценить. Так же можно используя входящую в поставку утилиту pgAdmin подключиться к базе, раскрыть "Схемы"-"public", и сформировать отчет по статистике для элемента "Таблицы".

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

При настройке сервера для тестирования я полагался на следующие расчеты:
Всего 4Гб ОЗУ. Потребители - ОС Windows, сервер 1С, PostgreSQL и дисковый кэш системы. Я исходил из того что для СУБД можно выделить до 2.5Гб ОЗУ

Значения могут указываться с суффиксами kB, MB, GB (значения в килобайта, мегабайтах или гигабайтах). После изменения значений требуется перезапустить службу PostgreSQL.

shared_buffers - Общий буфер сервера

Размер кэша чтения и записи PostgreSQL, общего для всех подключений. Если данные отсутствуют в кэше, производится чтение с диска (возможно, будут кэшированы ОС)

Если объём буфера недостаточен для хранения часто используемых рабочих данных, то они будут постоянно писаться и читаться из кэша ОС или с диска, что крайне отрицательно скажется на производительности.

Но это не вся память, требуемая для работы, не следует указывать слишком большое значение, иначе не останется памяти как для собственно выполнения запросов клиентов (а чем их больше тем выше потребление памяти), так и для ОС и прочих приложений, например, процесса сервера 1С. Так же сервер полагается и на кэш ОС и старается не держать в своём буфере то что скорее всего закэшировано системой.

Начальные рекомендации:
Средний объем данных, доступно 256-512Мб - значения 16-32Мб
Большой объем данных, доступно 1-4Гб - значения 64-256Мб или выше.

В тесте использовалось

work_mem - память для сортировки, агрегации данных и т.д.

Выделяется на каждый запрос, возможно по нескольку раз для сложных запросов. Если памяти недостаточно - PostgreSQL будет использовать временные файлы. Если значение слишком большое - может возникнуть перерасход оперативной памяти и ОС начнет использовать файл подкачки с соответствующим падением быстродействия.

Есть рекомендация при расчетах взять объем доступной памяти за вычетом shared_buffers , и поделить на количество одновременно исполняемых запросов. В случае сложных запросов делитель стоит увеличить, т.е. уменьшить результат. Для рассматриваемого случая из расчета 5 активных пользователей (2.5Гб-0.5Гб (shared_buffers))/5=400Мб. В случае если СУБД сочтет запросы достаточно сложными, или появятся дополнительные пользователи, потребуется значение уменьшить.

Для простых запросов достаточно небольших значений - до пары мегабайт, но для сложных запросов (а это типовой сценарий для 1С) потребуется больше. Рекомендация - для памяти 1-4Гб можно использовать значения 32-128Мб. В тесте использовал

maintenance_work_mem - память для команд сбора мусора, статистики, создания индексов.

Рекомендуется устанавливать значение 50-75% от размера самой большой таблицы или индекса, но чтобы памяти хватило для работы системы и приложений. Рекомендуется устанавливать значения больше чем work_mem. В тесте использовал
maintenance_work_mem = 192MB

temp_buffers - буфер под временные объекты, в основном для временных таблиц.

Можно установить порядка 16 МБ. В тесте использовал
temp_buffers = 32MB

effective_cache_size - примерный объем дискового кэша файловой системы.

Оптимизатор использует это значение при построении плана запроса, для оценки вероятности нахождения данных в кэше (с быстрым случайным доступом) или на медленном диске. В Windows текущий объем памяти, выделенной под кэш, можно посмотреть в диспетчере задач.

Autovacuum - "сборка мусора"

PostgreSQL как типичный представитель "версионных" СУБД (в противоположность блокирующим) самостоятельно не блокирует при изменении данных таблицы и записи от читающих транзакций (в случае 1С этим занимается сам сервер 1С). Вместо этого создаётся копия изменяемой записи, которая становится видна последующим транзакциям, действующие же продолжают видеть данные, актуальные на начало своей транзакции. Как следствие, в таблицах накапливаются устаревшие данные - предыдущие версии измененных записей. Для того чтобы СУБД могла высвободившееся место использовать, необходимо произвести "сборку мусора" - определить какие из записей больше не используются. Это можно сделать явно SQL-командой VACUUM , либо дождаться когда таблицу обработает автоматический сборщик мусора - AUTOVACUUM. Так же до определенной версии сборка мусора была связана со сбором статистики (планировщик использует данные о количестве записей в таблицах и распределении значений индексированных полей для построения оптимального плана запроса). С одной стороны, сбор мусора делать необходимо, чтобы таблицы не разрастались и эффективно использовали дисковое пространство. С другой внезапно начавшаяся уборка мусора дает дополнительную нагрузку на диск и таблицы, что приводит к увеличению времени выполнения запросов. Аналогичный эффект создает автоматический сбор статистики (явно его можно запустить командой ANALYZE или совместно со сборкой мусора VACUUM ANALYZE ). И хотя от версии к версии PostgreSQL совершенствует эти механизмы, чтобы минимизировать негативное влияние на производительность (например, в ранних версиях сборка мусора полностью блокировала доступ к таблице, с версии 9.0 работа VACUUM ускорена), тут есть что настроить.

Полностью отключить autovacuum можно параметром:

Так же для работы Autovacuum требуется параметр track_counts = on, в противном случае он работать не будет.

По умолчанию оба параметра включены. На самом деле autovacuum полностью отключить нельзя - даже при autovacuum = off иногда (после большого количества транзакций) autovacuum будет запускаться.

Отключать autovacuum крайне не рекомендуется, иначе имеет смысл самостоятельно запланировать регулярное выполнение команды VACUUM ANALYZE .

Замечание: VACUUM обычно не уменьшает размер файла таблицы, только помечает свободные, доступные для повторного использования области. Если же требуется физически высвободить лишнее место и максимально уменьшить занимаемое пространство на диске, потребуется команда VACUUM FULL . Этот вариант блокирует доступ к таблице на время работы, и обычно не требуется его использовать. Подробнее об использовании команды VACUUM можно прочитать в документации (на английском).

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

autovacuum_max_workers - максимальное количество параллельно запущенных процессов уборки.

autovacuum_naptime - минимальный интервал, реже которого autovacuum не будет запускаться. По умолчанию 1 минута. Можно увеличить, тогда при частых изменениях данных анализ будет выполняться реже.

autovacuum_vacuum_threshold, autovacuum_analyze_threshold - количество измененных или удаленных записей в таблице, необходимых для запуска процесса сборки мусора VACUUM или сбора статистики ANALYZE . По умолчанию по 50.

autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - коэфициент от размера таблицы в записях, добавляемый к autovacuum_vacuum_threshold и autovacuum_analyze_threshold соответственно. Значения по умолчанию 0.2 (т.е. 20% от количества записей) и 0.1 (10%) соответственно.

Рассмотрим пример с таблицей на 10000 записей. Тогда при настройках по умолчанию после 50+10000*0.1=1050 измененных или удаленных записей будет запущен сбор статистики ANALYZE , а после 2050 изменений - сборка мусора VACUUM .

Если увеличить threshold и scale_factor, обслуживающие процессы будут выполняться реже, но небольшие таблицы могут существенно разрастаться. Если БД состоит преимущественно из небольших таблиц, общее увеличение занимаемого дискового пространства может быть существенным, таким образом увеличивать эти значения можно, но с умом.

Таким образом может иметь смысл увеличить интервал autovacuum_naptime, и несколько увеличить threshold и scale_factor. В нагруженных базах может быть альтернативой существенно поднять scale_factor (значение 1 позволит "разбухать" таблицам вдвое) и поставить в планировщик ежесуточное выполнение VACUUM ANALYZE в период минимальной загруженности БД.

default_statistics_target - назначает объем статистики, собираемый командой ANALYZE . Значение по умолчанию 100. Большие значения увеличивают время выполнения команды ANALYZE, но позволяют планировщику строить более эффективные планы выполнения запросов. Встречаются рекомендации по увеличению до 300.

Можно управлять производительностью AUTOVACUUM, делая его более длительным но менее нагружающим систему.

vacuum_cost_page_hit - размер "штрафа" за обработку блока, находящегося в shared_buffers. Связан с необходимостью блокировать доступ к буферу. Значение по умолчанию 1

vacuum_cost_page_miss - размер "штрафа" за обработку блока на диске. Связан с блокировкой буфера, поиском данных в буфере, чтении данных с диска. Значение по умолчанию 10

vacuum_cost_page_dirty - размер "штрафа" за модификацию блока. Связан с необходимостью сбросить модифицированные данные на диск. Значение по умолчанию 20

vacuum_cost_limit - максимальный размер "штрафов", после которых процесс сборки может быть "заморожен" на время vacuum_cost_delay. По умолчанию 200

vacuum_cost_delay - время "заморозки" процесса сборки мусора по достижению vacuum_cost_limit. Значение по умолчанию 0ms

autovacuum_vacuum_cost_delay - время "заморозки" процесса сборки мусора для autovacuum. По умолчанию 20ms. Если установить -1, будет использоваться значение vacuum_cost_delay

autovacuum_vacuum_cost_limit - максимальный размер "штрафа" для autovacuum. Значение по умолчанию -1 - используется значение vacuum_cost_limit

По сообщениям использование vacuum_cost_page_hit = 6 , vacuum_cost_limit = 100 , autovacuum_vacuum_cost_delay = 200ms уменьшает влияние AUTOVACUUM до 80%, но увеличивает время его выполнения втрое.

Настройка записи на диск

При завершении транзакции PostgreSQL начала пишет данные в специальный журнал транзакций WAL (Write-ahead log), а затем уже в базу после того, как данные журнала гарантированно записаны на диск. По умолчанию используется механизм fsync, когда PostgreSQL принудительно сбрасывает данные (журнала) из дискового кэша ОС на диск, и только после успешной записи (журнала) клиенту сообщается об успешном завершении транзакции. Использование журнала транзакций позволяет завершить транзакцию или восстановить базу если во время записи данных произойдет сбой.

В нагруженных системах с большими объемами записи может иметь смысл вынести журнал транзакций на отдельный физический диск (но не на другой раздел этого же диска!). Для этого нужно остановить СУБД, перенести каталог pg_xlog в другое место, а на старом месте создать символическую ссылку, например, утилитой junction. Так же ссылки умеет создавать Far Manager (Alt-F6). При этом надо убедиться что новое место имеет права доступа для пользователя, от которого запускается PostgreSQL (обычно postgres).

При большом количестве операций изменения данных может потребоваться увеличить значение checkpoint_segments, регулирующее объем данных, который может ожидать переноса из журнала в саму базу. По умолчанию используется значение 3. При этом следует учитывать что под журнал выделяется место, расчитываемое по формуле (checkpoint_segments * 2 + 1) * 16 МБ, что при значении 32 уже потребует более 1Гб места на диске.

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

fsync = off
full_page_writes = off

Делать это можно только в случае если вы на 100% доверяете оборудованию и ИБП (источнику бесперебойного питания). Иначе в случае аварийного завершения системы есть риск получить разрушенную БД. И в любом варианте не помешает так же RAID-контроллер с батарейкой для питания памяти недозаписанных данных.

Определенной альтернативой может быть использование параметра

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

Если не отключать fsync совсем, можно указать метод синхронизации в параметре. Статья с диска ИТС ссылается на утилиту pg_test_fsync, но в моей сборке PostgreSQL её не оказалось. По утверждению 1С, в их случае в Windows оптимально себя показал метод open_datasync (судя по всему, именно этот метод и используется по умолчанию).

В случае если используется множество мелких пишущих транзакций (в случае 1С этом может быть массовое обновление справочника вне транзакции), может помочь сочетание параметров commit_delay (время задержки завершения транзакции в микросекундах, по умолчанию 0) и commit_siblings (по умолчанию 5). При включении опций завершение транзакции может быть отложено на время commit_delay, если в данный момент исполняется не менее commit_siblings транзакций. В этом случае результат всех завершившихся транзакций будет записан совместно для оптимизации записи на диск.

Прочие параметры, влияющие на производительность

wal_buffers - объем памяти в shared_buffers для ведения транзакционных логов. Рекомендация - при 1-4Гб доступной памяти использовать значения 256КБ-1МБ. Документация утверждает что использование значения "-1" автоматически подбирает значение в зависимости от значения shared_buffers.

random_page_cost - "стоимость" случайного чтения, используется при поиске данных по индексам. По умолчанию 4.0. За единицу берется время последовательного доступа к данным. Для быстрых дисковых массивов, особенно SSD, имеет смысл понижать значение, в этом случае PostgreSQL будет более активно использовать индексы.

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

Параметры из раздела QUERY TUNING, особенно касающиеся запрета планировщику использовать конкретные методы поиска, рекомендуется изменять только в том случае если есть полное понимание что делаете. Очень легко оптимизировать один вид запросов и обрушить производительность всех остальных. Эффективность изменения большинства параметров в этом разделе зависит от данных в БД, запросов к этим данным (т.е. от используемой версии 1С в т.ч.) и версии СУБД.

Заключение

PostgreSQL - мощная СУБД в умелых руках, но требующая тщательной настройки. Его вполне можно использовать совместно с 1С и получить приличное быстродействие, а бесплатность его будет очень приятным бонусом.

Критика и дополнения к этой статье приветствуются.

Полезные ссылки

http://www.postgresql.org/docs/9.2/static/ - официальная документация на PostgreSQL (на английском)

Статьи с диска ИТС по настройке PostgreSQL

История правок статьи

• 29.01.2015 - опубликована первоначальная версия
• 31.01.2015 - статья дополнена разделом по AUTOVACUUM, добавлена ссылка на оригинальную документацию.

В дальнейшем я намерен провести тестирование работы СУБД в режиме добавления и изменения данные.