Postgresql

Установка платформы 1С 8.3.20.1363 и более старших версий на RHEL8 и любые другие rpm-based linux. Решение проблемы установки меньших версий 1С8.3 (webkitgtk3) на RHEL 8 / CentOS 8 / Fedora Linux

Начиная с версии платформы 1С 8.3.20.1363 реализована программа установки компонентов системы «1С:Предприятие» для ОС Linux. Теперь любой пользователь Линукс может без проблем установить 1С на свою любимую систему. Попытка установки 1С:Предприятия 8.3 меньших версий, чем 1С 8.3.20.1363 на RedHat Enterprise Linux 8 / CentOS 8 / Fedora не увенчается успехом, произойдет ошибка: Неудовлетворенные зависимости: libwebkitgtk-3.0.so.0()(64bit) нужен для 1c-enterprise-8.3.18.1128-training-8.3.18-1128.x86_64. Конфликт заключается в том, что 1С требует устаревшую версию пакета libwebkitgtk-3.0.so.0()(64bit), запрещенную из-за проблем безопасности, и не может работать с актуальной версией пакета webkit2gtk3. Гуглить в интернете можно долго, хочу поделиться с Вами уже найденным рабочим решением в конце данной статьи.

What is PostgreSQL?

PostgreSQL is a powerful, open source object-relational database system that uses and extends the SQL language combined with many features that safely store and scale the most complicated data workloads. The origins of PostgreSQL date back to 1986 as part of the POSTGRES project at the University of California at Berkeley and has more than 30 years of active development on the core platform.

PostgreSQL has earned a strong reputation for its proven architecture, reliability, data integrity, robust feature set, extensibility, and the dedication of the open source community behind the software to consistently deliver performant and innovative solutions. PostgreSQL runs on all major operating systems, has been ACID-compliant since 2001, and has powerful add-ons such as the popular PostGIS geospatial database extender. It is no surprise that PostgreSQL has become the open source relational database of choice for many people and organisations.

Getting started with using PostgreSQL has never been easier — pick a project you want to build, and let PostgreSQL safely and robustly store your data.

Утилиты (программы) PosgreSQL:

• createdb и dropdb – создание и удаление базы данных (соответственно)
• createuser и dropuser – создание и пользователя (соответственно)
• pg_ctl – программа предназначенная для решения общих задач управления (запуск, останов, настройка параметров и т.д.)
• postmaster – многопользовательский серверный модуль PostgreSQL (настройка уровней отладки, портов, каталогов данных)
• initdb – создание новых кластеров PostgreSQL
• initlocation – программа для создания каталогов для вторичного хранения баз данных
• vacuumdb – физическое и аналитическое сопровождение БД
• pg_dump – архивация и восстановление данных
• pg_dumpall – резервное копирование всего кластера PostgreSQL
• pg_restore – восстановление БД из архивов (.tar, .tar.gz)

Примеры создания резервных копий:

Создание бекапа базы mydb, в сжатом виде

pg_dump -h localhost -p 5440 -U someuser -F c -b -v -f mydb.backup mydb

Создание бекапа базы mydb, в виде обычного текстового файла, включая команду для создания БД

pg_dump -h localhost -p 5432 -U someuser -C -F p -b -v -f mydb.backup mydb

Создание бекапа базы mydb, в сжатом виде, с таблицами которые содержат в имени payments

pg_dump -h localhost -p 5432 -U someuser -F c -b -v -t *payments* -f payment_tables.backup mydb

Дамп данных только одной, конкретной таблицы. Если нужно создать резервную копию нескольких таблиц, то имена этих таблиц перечисляются с помощью ключа -t для каждой таблицы.

pg_dump -a -t table_name -f file_name database_name

Создание резервной копии с сжатием в gz

pg_dump -h localhost -O -F p -c -U postgres mydb | gzip -c > mydb.gz

Список наиболее часто используемых опций:

• -h host — хост, если не указан то используется localhost или значение из переменной окружения PGHOST.
• -p port — порт, если не указан то используется 5432 или значение из переменной окружения PGPORT.
• -u — пользователь, если не указан то используется текущий пользователь, также значение можно указать в переменной окружения PGUSER.
• -a, —data-only — дамп только данных, по-умолчанию сохраняются данные и схема.
• -b — включать в дамп большие объекты (blog’и).
• -s, —schema-only — дамп только схемы.
• -C, —create — добавляет команду для создания БД.
• -c — добавляет команды для удаления (drop) объектов (таблиц, видов и т.д.).
• -O — не добавлять команды для установки владельца объекта (таблиц, видов и т.д.).
• -F, —format {c|t|p} — выходной формат дампа, custom, tar, или plain text.
• -t, —table=TABLE — указываем определенную таблицу для дампа.
• -v, —verbose — вывод подробной информации.
• -D, —attribute-inserts — дамп используя команду INSERT с списком имен свойств.

Бекап всех баз данных используя команду pg_dumpall.

pg_dumpall > all.sql

Восстановление таблиц из резервных копий (бэкапов):

psql — восстановление бекапов, которые хранятся в обычном текстовом файле (plain text);
pg_restore — восстановление сжатых бекапов (tar);

Восстановление всего бекапа с игнорированием ошибок

psql -h localhost -U someuser -d dbname -f mydb.sql

Восстановление всего бекапа с остановкой на первой ошибке

psql -h localhost -U someuser —set ON_ERROR_STOP=on -f mydb.sql

Для восстановления из tar-арихива нам понадобиться сначала создать базу с помощью CREATE DATABASE mydb; (если при создании бекапа не была указана опция -C) и восстановить

pg_restore —dbname=mydb —jobs=4 —verbose mydb.backup

Восстановление резервной копии БД, сжатой gz

gunzip mydb.gz
psql -U postgres -d mydb -f mydb

Оператор SELECT

Как упоминалось в начале статьи, SQL-запросы почти всегда начинаются с оператора SELECT. SELECT в запросах указывает, какие столбцы из таблицы должны нужно вернуть в наборе результатов. Запросы также почти всегда включают оператор FROM, который используется для указания таблицы, к которой нужно обратиться.

В общем SQL-запросы следуют такому синтаксису:

Например, чтобы извлечь столбец name из таблицы dinners, нужен такой запрос:

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

Вместо того чтобы называть конкретный столбец или набор столбцов, вы можете использовать оператор SELECT со звездочкой (*) – она служит заполнителем, представляющим все столбцы в таблице. Следующая команда отобразит все столбцы таблицы tourneys:

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

Оператор сравнения в выражении WHERE определяет способ сравнения указанного столбца со значением. Вот некоторые распространенные операторы сравнения SQL:

Оператор	Действие
=	Равно
!=	Не равно
<	Меньше, чем
>	Больше, чем
<=	Меньше или равно
>=	Больше или равно
BETWEEN	проверяет, находится ли значение в заданном диапазоне
IN	проверяет, содержится ли значение строки в наборе указанных значений
EXISTS	проверяет, существуют ли строки при заданных условиях
LIKE	проверяет, соответствует ли значение указанной строке
IS NULL	Проверяет значения NULL
IS NOT NULL	Проверяет все значения, кроме NULL

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

SQL позволяет использовать подстановочных знаков, и это особенно удобно при работе с выражениями WHERE. Знак процента (%) представляют ноль или более неизвестных символов, а подчеркивания (_) представляют один неизвестный символ. Они полезны, если вы пытаетесь найти конкретную запись в таблице, но не знаете точно, что это за запись. Чтобы проиллюстрировать это, предположим, что вы забыли любимое блюдо нескольких своих подруг, но вы уверены, что это блюдо начинается на t. Вы можете найти его название с помощью запроса:

Исходя из вышеприведенного вывода, это tofu.

Иногда приходится работать с базами данных, в которых есть столбцы или таблицы с относительно длинными или трудно читаемыми названиями. В этих случаях вы можете сделать эти имена более читабельными, создав псевдонимы – для этого есть ключевое слово AS. Псевдонимы, созданные с помощью AS, являются временными (они существуют только на время запроса, для которого они созданы):

Как видите, теперь SQL отображает столбец name как n, столбец birthdate как b и dessert как d.

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

Другие типы данных

• pg_trgm позволяет определять «похожесть» слов, сравнивая количество совпадающих последовательностей из трех букв (триграмм). Добавляются два класса операторов, gist_trgm_ops и gin_trgm_ops, поддерживающих разные операторы, в том числе сравнение с помощью LIKE и регулярных выражений. Это расширение можно использовать вместе с полнотекстовым поиском для того, чтобы предлагать варианты слов при опечатках.
• hstore реализует хранилище «ключ-значение». Для этого типа данных существуют классы операторов для разных методов доступа, в том числе и для GIN. Хотя, с появлением типа данных jsonb, использовать hstore уже нет особых причин.
• intarray расширяет функциональность целочисленных массивов. Индексная поддержка включает как GiST, так и GIN (класс операторов gin__int_ops).

• btree_gin добавляет GIN-поддержку для обычных типов данных, чтобы использовать их в многоколоночном индексе вместе со сложносоставными типами.
• jsquery определяет язык запросов к JSON и класс операторов для его индексной поддержки. Это расширение не входит в стандартную поставку PostgreSQL.

Установка MS SQL и PostgreSQL

Давайте сравним установку PostgreSQL и MS SQL Server на Windows.

• Чтобы поставить MS SQL-сервер, надо скачать 2,5 Гб с интернета.

• При этом дистрибутив Postgres для Windows – 70 Мб.

• В процессе инсталляции для MS SQL Server, нам надо сделать 12 кликов и пройти два окна настройки параметров, где мы сразу можем настроить: количество и расположение файлов для tempDB, а также расположение базы данных и лога транзакций. Время инсталляции SQL-сервера с учетом скачивания дистрибутивов – 4 часа.

• «Виндовый» Postgres настраивается в 5 кликов (там всего одно окно настройки), почти все параметры проходят автонастройку, опираясь на параметры вашего компьютера. Я сейчас говорю про дистрибутив от компании Postgres Pro (и платный, и бесплатный настраиваются одинаково). Время инсталляции – 5 минут. Если надо разнести файлы базы, WAL и временных файлов то тогда ещё три строчки в конфигурационном файле.

Дальше давайте теперь сравним установку на Linux. В данном случае будут рассматривать CentOS.

• Установка MS SQL-сервера на CentOS представляет собой 5 страниц инструкций с сайта Microsoft. Время инсталляции – час. В этот час будет скачиваться неслабый дистрибутив, и потом его нужно будет установить и настроить в командной строке. Время настройки – 15 минут.

  • Для самого MS SQL Server в CentOS нужно будет настроить хотя бы два параметра: это параллелизм и количество потребляемой оперативной памяти.

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

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

• Устанавливая на CentOS Postgres вам придет письмо с кодом в 12 строчек. Копируете, вставляете, и через 5 минут у вас есть запущенный и готовый Postgres. Для настройки Postgres в Windows и в CentOS вам нужно провести всего четыре настройки параметров сервера СУБД и задать две регламентные операции в cron. На это уйдет максимум 15 минут.

Все эти цифры по поводу настройки и установки пока не в пользу MS SQL.

Я свято уверен, что после настройки и установки в СУБД потом постоянно что-то крутить в настройках СУБД не нужно. Анализ проблем лучше делать в технологическом журнале 1С. Техжурнал 1С покажет более полную комплексную информацию, которая будет содержать не только «тормоза» СУБД, но и «тормоза» самого движка платформы, что часто занимает гораздо более длительное время в исполнении запросов чем время, которое тратит на этот запрос СУБД. И только когда вы нашли проблему, код 1С кажется идеальным а СУБД ведёт себя странно, вот тогда уже нужно идти и смотреть планы запросов, делать выводы и может быть менять настройки, хотя лучше всё таки поменять код 1С, так как улучшив одну операцию изменением настроек СУБД можно очень легко “положить” всю систему.

Вопросы

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

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

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

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

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

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

Завязка

Я поддерживаю относительно большой проект, в котором есть публичный поиск по документам. В базе лежит ~500 тысяч документов общим объемом ~3,6 Гб. Суть поиска такова: пользователь заполняет форму, в которой есть и полнотекстовый запрос, и фильтрация по множеству полей в БД, в том числе и с join-ами.

Поиск работает (точнее, работал) через Sphinx, и работал не очень хорошо. Основные проблемы были такими:

1. Индексирование отъедало порядка 8 Гб оперативной памяти. На сервере с 8 Гб ОЗУ это проблема. Память свопилась, это приводило к ужасной производительности.
2. Индекс строился примерно 40 минут. Ни о какой консистентности поисковых результатов речи не шло, индексирование запускалось раз в день.
3. Поиск работал долго. Особенно долго осуществлялись запросы, которым соответствовало большое количество документов: огромное количестов id-шников приходилось передавать из сфинкса в базу, и сортировать по релевантности на бэкэнде.

Из-за этих проблем возникла задача — оптимизировать полнотекстовый поиск. У этой задачи есть два решения:

1. Подтюнить Sphinx: настроить realtime-индекс, хранить в индексе атрибуты для фильтрации.
2. Использовать встроенный FTS PostgreSQL.

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

Казалось бы, хорошее решение. Но проблемы поджидали впереди.

Начнем с самого начала.

Индексы в PostgreSQL

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

Рассмотрим запрос:

Здесь выражение означает, что значение в колонке  удовлетворяет некоторому условию (предикату) .

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

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

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

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

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

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

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

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

И такой индекс уже может успешно применяться для ускорения нашего запроса.

В зависимости от типа индексируемых данных, для индексирования применяются разные подходы. По умолчанию при создании индекса используется индекс на основе B-дерева. Но PostgreSQL поддерживает разные типы индексов для очень широкого круга задач, и при необходимости мы можем указать другой тип индекса, отличный от B-tree. Для этого перед списком индексируемых полей необходимо указать директиву . Например, для использования индекса типа GiST:

Open Source-лицензированная база данных

В начале XXI века многие компьютерные системы создаются на основе свободно распространяемых программ с открытыми исходными кодами. К их числу относится и PostgreSQL. Что же это означает в действительности?

Когда понятие Open Source применяется к программному обеспечению, оно приобретает специальный смысл. Такое программное обеспечение поставляется вместе с исходными кодами. Это не обязательно значит, что на его применение не налагаются никакие условия. Оно все-таки лицензируется в том смысле, что вы получаете право некоторым образом использовать это программное обеспечение.

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

Если с программным обеспечением Open Source возникают проблемы, пользователь может или исправить ошибки сам (поскольку у него есть исходные тексты), или же передать код кому-то другому для исправления. Сейчас многие коммерческие компании предлагают поддержку продуктов Open Source, поэтому, приобретая такой продукт, не стоит чувствовать себя «забытым».

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

Наиболее либеральной является лицензия Berkeley Software Distribution (BSD), разрешающая делать с программным обеспечением все что угодно, не предоставляя при этом никаких гарантий. Лицензия на использование PostgreSQL по сути своей аналогична лицензии BSD, она представляет собой заявление об авторских правах, в котором говорится: «Настоящим предоставляется право на использование, копирование, модификацию и распространение данного программного продукта и относящейся к нему документации в любых целях, без оплаты и без подписания соответствующих соглашений при условии, что во всех копиях будет присутствовать уведомление об авторских правах, указанное выше, данный абзац и два последующих». Два следующих абзаца посвящены отказу от каких бы то ни было обязательств и гарантий.

Ресурсы по обучению PostgreSQL

1. Информация о базах данных в целом и о PostgreSQL в частности может быть получена из множества источников, как печатных, так и доступных через Интернет.
2. Тем, кого интересует тема свободного распространения и открытости исходных кодов в отношении программного обеспечения (Open Source продукты), советуем посетить два следующих сайта:

Получение информации о базе данных

Размер базы данных

Чтобы получить физический размер файлов (хранилища) базы данных, используем следующий запрос:

Результат будет представлен как число вида .

— функция, которая возвращает имя текущей базы данных. Вместо неё можно ввести имя текстом:

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

В результате получим информацию вида .

Перечень таблиц

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

— стандартная схема базы данных, которая содержит коллекции представлений (views), таких как таблицы, поля и т.д. Представления таблиц содержат информацию обо всех таблицах баз данных.

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

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

Размер таблицы

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

Функция возвращает объём, который занимает на диске указанный слой заданной таблицы или индекса.

Имя самой большой таблицы

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

Для того, чтобы вывести информацию о самой большой таблице, ограничим запрос с помощью :

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

Backend

	13	12	11	10	9.6	9.5	9.4	9.3	9.2	9.1	9.0	8.4	8.3	8.2	8.1
64-bit large objects	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No	No	No
	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No
	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No
Custom background workers	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No	No	No
Disk based FSM	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No
Dollar Quoting	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Dynamic Background Workers	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No	No	No	No
EXPLAIN (BUFFERS) support	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No
EXPLAIN (WAL) support	Yes	No	No	No	No	No	No	No	No	No	No	No	No	No	No
Holdable cursors	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Inserted data can trigger autovacuum	Yes	No	No	No	No	No	No	No	No	No	No	No	No	No	No
	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Loadable plugin infrastructure for monitoring the planner	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No
Multiple autovacuum workers	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No
Named restore points	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No
Parallelized VACUUM for Indexes	Yes	No	No	No	No	No	No	No	No	No	No	No	No	No	No
Parallel vacuumdb jobs	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No	No	No	No	No
Payload support for LISTEN/NOTIFY	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No
Prefix support for text search synonym dictionary	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No
Savepoints	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Serializable Snapshot Isolation	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No
SQLDA support for ECPG	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No
SQL-standard information schema	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Support for anonymous shared memory	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No	No	No	No
Two Phase commit	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
unnest/array_agg	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No
Updateable cursors	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No
Version aware psql	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No
Visibility Map for Vacuuming	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No
XML, JSON and YAML output for EXPLAIN	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	No	No	No	No

psql

На первом месте psql, и это неудивительно. Надежный как автомат калашникова, бесплатный, стоит из коробки, что еще надо для счастья? Для редактирования запросов используется редактор, указанный в переменной окружения EDITOR, обычно ставят vim, nano или что-то в этом духе. Ну и вообще, psql — это unix-way, т.е. можно его запускать со своим редактором, своим пейджером для отображения результатов, ему можно на вход подавать sql-запрос через пайп, и вывод направлять куда надо.

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

Ну, и работа в консоли и в виме — это не всех устраивает почему-то 🙂

На самом деле, иногда хочется иметь где-нибудь слева полный список таблиц/вьюх и иметь возможность щелкнуть мышкой по нужной, чтобы посмотреть, что там вообще. Т.е. хоть какой-то GUI. Работа в psql хоть и эффективна, но напоминает работу в темной комнате с маленьким фонариком, освещающим лишь только один объект за раз.

Путь поиска

Так называемое “Квалифицированное имя” состоит из явно указанной схемы и имени объекта (как абсолютный путь в файловой системе). Например: <схема.имя>.

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

В параметре search_path можно через запятую перечислить схемы, в которых нужно искать объект, если мы не указываем схему явно. search_path это что-то вроде переменной окружения PATH в Linux, для поиска команд.

Из search_path исключаются:

• несуществующие схемы;
• схемы к которым нет доступа.

А некоторые схемы всегда добавляются в search_path, даже если мы их туда не запишем. Например pg_catalog.

Реальное значение search_path показывает функция current_schemas().

postgres@postgres=# SELECT current_schemas(true);
   current_schemas
---------------------
 {pg_catalog,public}
(1 row)

Time: 1,945 ms

При создании нового объекта, он будет помещаться в первую указанную в search_path схему. Если посмотреть пример выше, то так как у нас нет права писать в схему pg_catalog, объекты будут создаваться в public.

Специальные схемы, временные объекты

К специальным схемам относят:

• public – по умолчанию входит в путь поиска, если ничего не менять, все объекты будут в этой схеме.
• Схема, одноимённая с пользователем – по умолчанию входит в search_path, но не существует. Если сделать, например схему postgres, то пользователь postgres будет по умолчанию работать с этой схемой.
• pg_catalog – схема для объектов системного каталога. Если pg_catalog не прописан, то это схема будет там подразумеваться первой.

Временные таблицы – существуют на время сеанса или транзакции. Они не журналируются и не попадают в общую память. Чтобы реализовать временную таблицу в postgres применяет временные схемы.

Схема pg_temp_N – автоматически создается для временных таблиц. Такая схема тоже по умолчанию находится в search_path. По окончанию все объекты временной схемы удаляются, а сама схема остается. Оставшаяся временная схема может использоваться для новых временных таблиц, новой транзакции или сеанса.

Технические характеристики

Доступны версии СУБД: PostgreSQL 11, 12, 13 и 11-TimescaleDB, 12-TimescaleDB, 13-TimescaleDB.

Для создания кластера БД доступны фиксированные и произвольные конфигурации нод.

Фиксированные конфигурации с предзаданным количеством ресурсов:

• 2 vCPU, 4 ГБ RAM, 32 ГБ локального диска;
• 2 vCPU, 8 ГБ RAM, 64 ГБ локального диска;
• 4 vCPU, 16 ГБ RAM, 128 ГБ локального диска;
• 8 vCPU, 32 ГБ RAM, 256 ГБ локального диска;
• 16 vCPU, 64 ГБ RAM, 512 ГБ локального диска;
• 32 vCPU, 128 ГБ RAM, 1024 ГБ локального диска.

В произвольных конфигурациях можно выбрать количество ресурсов:

• vCPU — от 1 до 8 ядер;
• RAM — от 4 ГБ до 64 ГБ;
• локальный диск — от 15 ГБ до 512 ГБ.

Примечание: на локальном диске зарезервировано около 5 ГБ под операционную систему, компоненты сервиса и хранение логов. Остальной объем доступен для размещения баз данных.

Кластеры БД можно создавать только в приватных и публичных сетях:

• Приватная сеть — к кластеру БД можно подключиться только из выбранной приватной сети;
• Публичная сеть — к кластеру БД можно подключиться из интернета.