Тюнинг производительности запросов в postgresql

Администрирование конфигураций 1С (недокументированные особенности работы)

Многие мои коллеги по работе и по профессии, уверен, сталкиваются с аналогичными ситуациями, когда программа 1С при работе с конфигурацией, мягко говоря, работает «странно». Как говорит один хороший знакомый (к слову, один из авторов УТ 11):
— «вот, ну согласись, нанять пару серьезных методистов — реальных дядечек с реального производства, до начала разработки — единственная ЭЛЕМЕНТАРНАЯ политика, как можно было этого не сделать???? там их НЕТ. Причем это 0 в плане затрат на разработку, там нет ограничений бюджета, это просто самый тупой прокол.»
В этой статье приведу способы лечения пресловутых проколов (за последний месяц).

1С:Предприятие Бухгалтерия переход с редакции 2.0 на 3.0. Практика перевода информационной базы для работы в управляемом приложении. Промо

Из информационного выпуска 1С № 16872 от 08.07.2013г. стало известно об относительно скором необходимом переходе на редакцию 1С:Бухгалтерия 3.0. В данной публикации будут разобраны некоторые особенности перевода нетиповой конфигурации 1С:Бухгалтерия 2.0 на редакцию 3.0, которая работает в режиме «Управляемое приложение».
Публикация будет дополняться по мере подготовки нового материала. Публикация не является «универсальной инструкцией».

Update 3. Права доступа. 14.08.2013
Update 4. Добавлен раздел 0. Дополнен раздел 4. Добавлен раздел 7. Внесены поправки, актуализирована информация. 23.11.2013.

1 стартмани

Второй раунд

Тут уже практически пользовательская нагрузка. Операция, на которой проводится тестирование, – восстановление последовательности партионного

учета управленческих партий. Это последняя УПП на момент тестирования, код типовой. Также типовой клиент, у которого итоги рассчитаны на полгода назад. Я не знаю, почему у клиентов такая амнезия по поводу этой регламентной операции, но никто не хочет следить за итогами. Почему, никто объяснить тоже не может. Поэтому берем типовой код, типового клиента, в самих партиях за месяц 150 тысяч документов, а строк в документах около 2 миллионов.

Все это делаем в 10 потоков. Это уже чуть-чуть не типовой этап, сделана определенная обработка, но внутри все запросы типовые.

В результате у нас получилось, что Postgres всего на 4% лучше. Делалось все очень долго – порядка 18 часов. И бухгалтеры будут вынуждены весь день не работать, чтобы дождаться результатов.

Поскольку результат получился не очень большой, плюс 4%, решили вместо

мельдония использовать что-нибудь похлеще. Второй в рейтинге вредных советов интернета на запрос «1С + Postgres тормозит» оказалась рекомендация отключить autovacuum. Отключили.

Результат получился еще хуже – примерно на 5%. То есть если бы мы изначально настроили систему с помощью этого вредного совета, мы бы вообще раунд полностью проиграли, было бы минус 0,6%.

На этом хочу остановиться чуть подробнее. Что за зверь такой autovacuum, зачем он нужен. И почему разработчики Postgres на каждой конференции твердят: «Не отключайте autovacuum!», но народ упорно его отключает. Попытаюсь объяснить, как говорят, на пальцах.

Чтобы понять, для чего нужен autovacuum, нужно понять, как Postgres работает с данными. Операция insert – записали строчку. Помимо строчки, пишется еще два служебных параметры x min и x max. В x min записывается номер транзакции, которая выполнила этот insert. Операция delete на самом деле ничего не удаляет, она просто в служебное поле строки x max записывает номер транзакции, которая ее удалила. Потом идет самая прикольная операция update. На самом деле нет такой операции, это просто delete + insert.

А в мире 1С, к сожалению, просто обожают работать задним числом: для пользователей не вопрос перевести месяц или год. То есть апдейтов миллионы. У нас не столько растут данные с помощью insert, сколько с помощью update, мы постоянно что-то обновляем. Из-за этого база имеет эффект распухания. Ладно, пусть раздувается, скажем админам, что это их проблемы, пусть увеличивают диски. Они увеличат. Но если было бы все так просто, никто не заморачивался бы. Проблема в том, что данные хранятся не где-то в сферическом вакууме, они хранятся в страницах. И когда у вас в страницах хранится куча мертвых данных, а в Postgres есть такое страшное понятие, как мертвые строчки, и когда вы делаете запрос базе данных, движок вынужден поднять все страницы с данными, отфильтровать данные, в которых x max пустой, и только с ними потом работать. Вы каждый раз заставляете Postgres ставить олимпийские рекорды по поднятию данных с дисков, чтобы выдать вам выборку.

Что делает autovacuum? Autovacuum – это своеобразный пылесос, он циклически и периодически идёт к каждой таблице вашей базы данных и делает выборку всех данных, где x max не пустой и чистит их физически. Теперь туда insert возможен, у вас на страницах будет больше живых данных, чем мертвых. Эффект – вам проще поднимать страницы. Это первое.

Второе. Помимо чистого autovacuum, есть еще такой фоновый процесс autovacuum analyze. Это аналог фонового обновления статистики в MS SQL. Без него планировщик никогда не узнает, что вы в таблицу добавили данные. Было в таблице 100 записей, добавили вы миллион записей, но планировщик свято уверен, что там их 100. И при любом запросе не парится и не ищет никакие индексы. Он просит TableScan, ему его дают, а там миллион записей. И вы сидите и ждете несколько минут.

Поэтому никогда не выключайте autovacuum. Надо его правильно настраивать, но ни в коем случае не отключать. Он имеет кучу настроек, и если у вас autovacuum настроен достаточно агрессивно, то есть он срабатывает на очень маленьком проценте изменения данных в таблицах, то вам не нужны даже ночные и недельные регламенты над базой данных, которые имеются у MS SQL. Ничего не надо делать, просто ничего. Кое-что делают только админы, если точно знают, что в этой таблице недавно удалили огромный массив данных, и ее нужно, грубо говоря, сжать. Тогда делается autovacuum full – это реструктуризация таблицы в понятиях 1С. Рядом создается табличка, куда и копируются данные.

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

1С:Предприятие Бухгалтерия переход с редакции 2.0 на 3.0. Практика перевода информационной базы для работы в управляемом приложении. Промо

1 стартмани

Псевдо роль public

Псевдо роль public не видна, но про неё следует знать. Это групповая роль, в которую включены все остальные роли. Это означает, что все роли по умолчанию будут иметь привилегии наследуемые от public. Поэтому иногда у public отбирают некоторые привилегии, чтобы отнять их у всех пользователей.

Роль public по умолчанию имеет следующие привилегии:

для всех баз данных:
- CONNECT – это означает что любая созданная роль сможет подключаться к базам данных, но не путайте с привилегией LOGIN;
- TEMPORARY – любая созданная роль сможет создавать временные объекты во всех база данных и объекты эти могут быть любого размера;
для схемы public:
- CREATE (создание объектов) – любая роль может создавать объекты в этой схеме;
- USAGE (доступ к объектам) – любая роль может использовать объекты в этой схеме;
для схемы pg_catalog и information_schema
USAGE (доступ к объектам) – любая роль может обращаться к таблицам системного каталога;

:
для всех функций

EXECUTE (выполнение) – любая роль может выполнять любую функцию. Ещё нужны ещё права USAGE на ту схему, в которой функция находится, и права к объектам к которым обращается функция.

:

Это сделано для удобства, но снижает безопасность сервера баз данных.

Сервер 1С:Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана

Если кратко описать мое отношение к Postgres: Использовал до того, как это стало мейнстримом.
Конкретнее: Собирал на нем сервера для компаний среднего размера (до 50 активных пользователей 1С).
На настоящий момент их набирается уже больше, чем пальцев рук пары человек (нормальных, а не фрезеровщиков).
Следуя этой статье вы сможете себе собрать такой же и начать спокойную легальную жизнь, максимально легко сделать первый шаг в мир Linux и Postgres.
А я побороться за 1. Лучший бизнес-кейс (лучший опыт автоматизации предприятия на базе PostgreSQL).
Если, конечно, статья придется вам по вкусу.

Получение данных

Зачастую нам нужно поделиться данными из postgres с сотрудниками, руководством или клиентами, причём желательно в каком-нибудь удобочитаемом формате типа CSV или Excel. Вы уже подготовили запрос, свели всё в одну таблицу, осталось только куда-нибудь это выгрузить. Погуглив psql csv export, можно найти 2 способа. Первый более примитивный.

CSV фйалы представляют собой просто строки со значениями, которые разделены запятыми. Таким образом, указав psql как форматировать вывод, можно получить похожую структуру. Тут есть одна большая проблема — если ваши данные содержат запятую, то её нужно экранировать, а т.к. количество полей может быть огромным, то такой способ ведёт в тупик.

Правильным способом будет выгрузка в CSV с помощью мета-команды или SQL команды . выглядит это примерно так:

накладывает несколько ограничений. Во-первых, путь к файлу должен быть абсолютным. Во-вторых, вы можете писать только на локальную файловую систему. То есть подключиться к удалённой БД и выгрузить данные на локальный компьютер не получится. И тут на помощь приходит \copy, которая представляет из себя всего лишь более удобную оболочку для COPY. Запрос выше можно переписать так:

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

Единственное ограничение состоит в том, что команда должна быть одной строкой. Причина в том, что окончанием выражения для команды с \ является перевод строки, а не точка с запятой. Это не касается — там управление передаётся в редактор. Под капотом выполняет всё тот же COPY, перенаправляя вывод в STDOUT вместо файла. Далее psql забирает со STDOUT и записывает в локальный файл.
Если вам нужно выгрузить данные в Excel, то убедитесь, что задали правильную кодировку. Он не дружит с UTF-8, так что лучше откатиться до latin1 (2015 год на дворе, я солидарен с негодованиями автора):

Если sql-запрос у вас находится в файле, то использовать его для команды не получится. Вам придётся скопировать всё тело запроса в выражение в команде, удалив переносы строк.

Наверно, я вам уже надоел, так что закругляюсь. Напоследок хотелось бы ещё рассказать про утилиту psql2csv. Она позволяет запускать запрос из файла и получать отформатированный CSV в STDOUT (который можно потом перенаправить в файл):

В случае запроса из файла:

Параметры вызова утилиты совпадают с параметрами psql. Вы можете заменить вызов psql на psql2csv, передав запрос в качестве аргумента, а на выходе получить валидный CSV. Но это ещё не всё — почему бы не подать вывод на вход какой-нибудь другой утилите?!
psql2csv также принимает аргументы для совместимости с Excel.

Я уже очень привык работать с PostgreSQL через командную строку. Всё, что раньше делал в pgAdmin, можно делать и тут, причём быстрее. Я надеюсь, что эта статья убедила вас сделать psql основным инструментом для работы с 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. В этом режиме для заблокированных таблиц запрещаются любые команды или параллельные блокировки любого уровня.

Бесплатный MS SQL vs бесплатный PostgreSQL

Нельзя сравнивать платный MS SQL – Standard и Enterprise – с бесплатным PostgreSQL, это не совсем корректное сравнение. Нельзя ожидать от бесплатного ПО такой же скорости, как и от платного, причем неслабо платного.

Давайте сравним бесплатную версию MS SQL Express и бесплатные версии PostgreSQL.

Бесплатные версии Postgres – это:

Самосборки, когда вы с сайта postgresql.org скачали исходники, добавили туда патчи для 1С и собрали свою сборку. Она бесплатна, пожалуйста, пользуйтесь.
То же самое можно сделать, скачав сборку, которую собрали специалисты фирмы «1С» с сайта – releases.1с.ru. Эта сборка будет отличаться от вашей самосборки тем, что она после сборки протестирована фирмой 1С.
Есть еще третий вариант – сайт 1с.postgres.ru. Это сборка от компании Postgres Professional – эта команда работает со своими серверами сборки, и они делают бесплатную версию для 1С. где в ванильную сборку добавляют несколько своих патчей, которые считают нужным. На то какие патчи они добавят, а какие – нет, мы с вами повлиять не можем. Но на моей практике сборка с 1с.postgres.ru работает намного стабильнее. Кто имеет доступ на партнерские форумы 1С, там есть несколько обращений, когда у людей сбоили самосборки или сборки с releases, при этом ставим сборки с 1с.postgres.ru с той же версией Postgres, и все отлично работает. Поэтому я бы советовал ставить отсюда.

Теперь давайте сравним бесплатные версии MS SQL Express и Postgres. Какие ограничения они накладывают:

На количество ядер.
- MS SQL Express в последней поддерживаемой 1С 17 версии, позволяет использовать только 4 ядра.
- бесплатный Postgres – безлимитное количество ядер.
То же самое по памяти.
- MS SQL Express может использовать 1,5 Гб памяти и все.
- Postgres – безлимитно.
Объем базы:
- MS SQL Express – 10 Гб,
- у Postgres – безлимитно.
Отказоустойчивость:
- в MS SQL Express не поддерживается вообще.
- В Postgres доступны логические и физические репликации любого уровня каскадирования. Вы можете одновременно делать с мастера десятки реплик. Или сделать реплику с мастера, а с реплики – еще одну (иногда это имеет смысл). Бесплатный Postgres позволит снимать бэкапы с реплики, не трогая этими задачами мастер.
- Есть несколько важных моментов:
  - бэкап у MS SQL консистентен на момент окончания бэкапа, а бэкап Postgres’a (dump) консистентен на момент начала бэкапа.
  - Если вы сливаете этот dumpс мастера Postgres (с главного сервера), то в момент этого бэкапа вы не сможете произвести структурные изменения в 1С, так как они содержат в себе команды drop для таблиц либо удаления столбцов. Postgres не позволит изменить структуру данных в части удаления, пока он снимает dump. Этот момент нужно учитывать при проектировании системы.
Регламентные операции плюс бэкапы
- На MS SQL Express регламенты можно делать только скриптами и cron. Нет там планировщика (агента SQL Server), его там не существует. Вы не сможете внутри SQL создать никаких расписаний или операций. Надо будет батнички нарисовать, засунуть это либо в cron, либо в планировщик Windows.
- То же самое на Postgres, все регламентные операции, бэкапы и восстановления из бэкапов – это скрипты, cron или планировщик Windows, смотря в какой системе вы это делаете.
Ещё момент – бесплатные версии обоих продуктов не входят в список импортозамещающих продуктов. Компаниям госсектора эти базы данных запрещены в использовании вообще, не только в 1С.
Также на бесплатном Postgres и бесплатном MS SQL нет ФСТЭКа. Никто не получает сертификаты ФСТЭК на эти продукты. Забегая вперед, скажу, что и в платном MS SQL ФСТЭКа нет.

С бесплатными версиями все более менее понятно, поехали в платные версии.

Предыстория

MS SQL – наш давний друг. И около 15 предыдущих лет мы жили с полной уверенностью, что для 1С нет лучшего выбора, чем MS SQL. Oracle — сильно дорого, IBM никто в живую не видел, а про Postgres на тот момент совсем ничего не было слышно.

Примерно пять лет назад в мире 1С начал появляться Postgres, за что большое спасибо команде Postgres Pro: Олегу Бартунову и Федору Сигаеву, которые продвинули эту СУБД. Как раз в это время у руководства нашей компании появилась задача резко вырасти в масштабах ИТ-инфраструктуры 1С. При этом была поставлена задача максимально сэкономить бюджет. Мой хороший друг, а по совместительству эксперт по техвопросам 1С сказал: «Антоха, кто не рискует, тот потом на Инфостарте не выступает!». И мы рискнули. И я выступаю на Инфостарте.

Вопросы

Насколько полезна сертификация на Postgres, что она дает?

Сертификация очень полезна, дает почти то же самое, что сертификация на 1С:Эксперта в фирме «1С». Вы вроде и так все знаете без сертификатов, но ваш путь поиска проблем, когда они возникнут, очень долгий, поскольку он неправильный, он идет не так. А тут учат именно структурированию – как правильно искать, что где искать, как пользоваться инструментами, которые дают гораздо более быстрый результат, чем те, к которым вы привыкли. Поэтому крайне полезно. Фактически, это некий чек-лист и список инструментов, который можно использовать. При том, что подготовка к сертификации – это просмотр бесплатных видео, которые у них на сайте лежат. Просматривайте видео, выполняете задания, которые там даны, и вперед на сертификацию.

Дает ли возможность 1С перенести базу с MS SQL на PostgreSQL?

Конечно, выгружаем в dt-ник и загружаем. Если база очень большая, нужно просто посмотреть, что там лежит. Я не удивлюсь, что это вложенные файлы — уберите их из БД на дисковые тома Есть ещё лайфхак – почистите итоги перед переносом в dt-ник (truncate таблиц итогов на СУБД — делать только если точно понимаешь что делаешь). А после того, как вы загрузили в dt-ник, посчитайте их заново. Заодно порядок в итогах наведете. Тем более, что в платформе 8.3.18 включили многопоточный расчет итогов.

*************

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе «PostgreSQL VS Microsoft SQL». Больше статей можно прочитать здесь.

Установка RedHat Enterprise Linux 8 (RHEL 8.4). Подключение RHEL8 к домену Active Directory. Запуск терминального клиента.

Операционная система – это один из краеугольных камней в фундаменте организации. От нее напрямую зависит надежность и безопасность корпоративной IT-инфраструктуры. Red Hat Enterprise Linux разработана с учетом всех требований и особенностей коммерческой эксплуатации Linux в производственной среде. Она проста в администрировании и управлении при развертывании приложений в физических, виртуальных и облачных средах. Обеспечивает высокую производительность и доступность приложений, а также обладает достаточной гибкостью, чтобы поддерживать рост организации и внедрение новых решений. Red Hat Enterprise Linux ценят за надежность, безопасность, стабильность, высокую производительность и масштабируемость, которые платформа предоставляет организациям. Клиентские решения Red Hat Enterprise Linux переносят эти инновации на рабочий стол.

Администрирование конфигураций 1С (недокументированные особенности работы)

Взаимодействие psql с операционной системой

Терминал psql умеет выполнять команды операционной системы. Для этого нужно использовать команду “\!“. Например так:

postgres=# \! hostname
s-pg13

Можно установить переменную окружения в систему с помощью команды \setenv:

postgres=# \setenv TEST Hello
postgres=# \! echo $TEST
Hello

А для того чтобы перевести вывод команд в файл нужно использовать ‘\o имя_файла’. И чтобы вернуть всё обратно используем “\o” без имени файла. Например:

postgres=# \o dba.log

postgres=# SELECT schemaname, tablename, tableowner FROM pg_tables LIMIT 5;

postgres=# \! cat dba.log
----------------------
schemaname | pg_catalog
tablename  | pg_statistic
tableowner | postgres
----------------------
schemaname | pg_catalog
tablename  | pg_type
tableowner | postgres
----------------------
schemaname | pg_catalog
tablename  | pg_foreign_table
tableowner | postgres
----------------------
schemaname | pg_catalog
tablename  | pg_authid
tableowner | postgres
----------------------
schemaname | pg_catalog
tablename  | pg_statistic_ext_data
tableowner | postgres

postgres=# \o

postgres=# \x
Expanded display is off.

В предыдущем листинге с помощью последней команды мы выключили расширенный режим.

Помимо вывода в файл psql умеет выполнять команды из файла. Это делается с помощью команды “\i имя файла”. Вот пример:

postgres=# \q

postgres@s-pg13:~$ cat <<EOT >> dba1.log
> SELECT 'pg_statistic: '|| count(*) FROM pg_statistic;
> SELECT 'pg_type: '|| count(*) FROM pg_type;
> SELECT 'pg_foreign_table: '|| count(*) FROM pg_foreign_table;
> EOT

postgres@s-pg13:~$ psql
psql (13.3)
Type "help" for help.

postgres=# \! cat dba1.log
SELECT 'pg_statistic: '|| count(*) FROM pg_statistic;
SELECT 'pg_type: '|| count(*) FROM pg_type;
SELECT 'pg_foreign_table: '|| count(*) FROM pg_foreign_table;

postgres=# \a \t \pset fieldsep ' '
Output format is unaligned.
Tuples only is on.
Field separator is " ".

postgres=# \i dba1.log
pg_statistic: 402
pg_type: 411
pg_foreign_table: 0

postgres=# \a \t \pset fieldsep '|'
Output format is aligned.
Tuples only is off.
Field separator is "|".

В примере выше мы проделали следующее:

вышли из psql;
создали скрипт dba1.log, который подсчитывает количество строк из:
- pg_statistic – статистическая информация о содержимом базы данных;
- pg_type – информация о типах данных;
- pg_foreign_table – дополнительная информация о сторонних таблицах.
обратно вернулись в psql;
прочитали файл dba1.log;
изменили формат вывода;
выполнили скрипт sql команд;
вернули формат вывода в прежнее состояние.