Тонкости эксплуатации PostgreSQL

Меня зовут Антон Дорошкевич, я – руководитель проектов во Франчайзинговой сети ИнфоСофт.

Именно я – тот человек, который шесть лет вам говорил, что 1С с PostgreSQL работает, и там все хорошо. Кто-то в это верил, кто-то – не верил. Но судя по тому, что вы все здесь, там действительно все хорошо. Если было бы плохо, сюда бы пришло два человека, у которых почему-то все хорошо, а у остальных все плохо.

Поэтому и доклад называется «Тонкости эксплуатации». Потому что «толстостей» там уже не осталось. Ставишь, и оно работает. И это – самая удивительная вещь.

Оно действительно работает. На всех современных конфигурациях, кроме ERP))).

На ERP тоже работает – все, кроме расчета себестоимости.

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

Мой оптимизм основан не на книгах, не на документации, а на реальном опыте перевода больших баз и больших клиентов с MS SQL на PostgreSQL.

Большие клиенты – это клиенты, входящие в список РБК 500 – топ 500 компаний страны. Если уж у них все работает, поверьте, у вас, если вы в этот список еще не входите, тоже все заработает.

Основной момент, на который надо обратить внимание, это ваши кастомизации кода.

Самый последний опыт перехода – переводили ЗУП, Управление холдингом, Документооборот. Очень большая нагрузка, базы на много терабайт – сейчас база до терабайта вообще не считается большой. Пользователей много – тоже сотни, где-то даже тысяча.

Так вот, мы во время перехода не поправили ни одной строчки типового кода вообще. Все, что мы оптимизировали, касалось внешних обработок, отчетов и массовых операций, которые сделаны «поверх» типового кода. Если сформировать и провести документ на одного человека – быстро и примерно одинаково на MS SQL и на PostgreSQL, то когда начинаешь формировать на 15 тысяч, вылазят всякие интересные моменты.

И вот именно об этих моментах мы с вами и будем сегодня говорить.

Настройка PostgreSQL

Настраивается PostgreSQL сейчас гораздо проще, чем MS SQL. Вообще ничего не надо трогать.

Есть два лагеря адептов разного PostgreSQL – есть 1С-сборка от Postgres Pro и есть 1С-сборка от фирмы 1С.

Если у вас религия или убеждения, или шеф не разрешают ставить сборку 1С от Postgres Pro, ставьте с сайта 1С, но рядом втихую поставьте сборку от Postgres Pro, возьмите оттуда настроечный файл (он сформируется автоматически и настроит все под ваше железо) и положите в файлы сборки от 1С. Больше ничего делать не нужно.

Там останется подправить один параметр – random page cost – согласно вашим дискам, и все, PostgreSQL настроен. Одна настройка на весь PostgreSQL.

Страх, что PostgreSQL сложно настраивать, у вас уже давно должен был пройти.

Да, потом вы, может быть, что-то подкрутите. Например, степень параллелизма, с которой все администраторы обожают экспериментировать: «Сейчас как врублю, и отчет залетает». Всё остальное встанет колом, зато отчет будет быстрый. Это надо крутить аккуратно, экспертно, понимая что делаешь, и так далее.

Страх перед PostgreSQL давно прошел. Страх, что он тормозит, тоже должен уйти. Ничего не тормозит, все работает. Но есть нюансы, есть тонкости…

Особенности работы с СХД

Первая тонкость – PostgreSQL и СХД несовместимы. При том, что мир КОРП так устроен, что там системы без СХД практически не существуют. Редко у КОРПов увидишь сервер с дисками NVMe.

Что значит несовместимы? Насколько несовместимы? Не то что прям – все пропало. Нет, нормально все работает.

Пока вы боретесь в запросах за секунды, хотите, чтобы запрос был не 5 секунд, а 4 секунды, 3 секунды – все прекрасно. На хорошей СХД (а на экране хорошая СХД, например) все работает прекрасно.

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

Смотрите, как выросла платформа 1С – мы уже боремся в запросах за миллисекунды! Например, нам нужно, чтобы этот запрос, который потом будет выполняться 6 миллионов раз, занимал 6 миллисекунд, а не 13. Потому что так нужно бизнесу. Иначе мы не успеем провести закрытие месяца. И начинается борьба…

Первый убийца миллисекунд – это СХД. Вам админы будут говорить: «Там IOPS целый камаз, у нас сеть 40-ка гигабитная». И это все правда. Они не врут, так и есть. Но только толку от этого почти ноль. Это, конечно, лучше, чем 100 мегабитная сеть для СХД, но в целом толку для СУБД почти ноль, потому что там на каждое обращение теряются миллисекунды.

А когда вы обращаетесь к железному диску, к NVMe, к флеш-накопителю – они не теряются. Поэтому, если есть возможность, откажитесь от СХД на проде.

Когда мы поднимаем такой вопрос перед заказчиком, нам обычно говорят: «Вы что, у нас же баз триллиарды», а потом оказывается, что все эти базы на среде разработки и тестирования. А на проде база одна.

Другое дело, что вы потом каждую ночь на среду разработки 500 ее копий разворачиваете. А разработчики пусть мучаются – чем хуже железо в разработке, тем лучше код 1С!)))

Ваши параметры на проде должны быть огромные, но у разработчиков все должно тормозить. Как у нас разработчики меряют, быстро ли работает 1С? По одному единственному параметру – конфигуратор у него быстро с утра запустился или нет? Если медленно, то 1С тормозит. И виноват в этом PostgreSQL, ага…. А то, что там СУБД вообще не участвует, никому не интересно. Поэтому среда разработки или тестирования может быть на СХД.

Да и для прода – если нет другого варианта, тоже используйте СХД. Но знайте, что маленькие запросики станут чуть медленнее на 3-5 миллисекунд каждый.

Когда запрос длится несколько секунд – вам все равно. А когда запрос длился 6 миллисекунд, а стал 9 – у вас время выполнения этой массовой операции увеличилось на 50%. У вас какая-то массовая обработка на железе проходила 4 часа, а после перехода на СХД – стала 6 часов. Это плохо.

Почему это плохо для PostgreSQL? Мы же в мире 1С в любом случае все сравниваем с MS SQL. С файловой базой, я надеюсь, уже никто не сравнивает, Oracle почти никто не видел, об IBM DB 2 почти никто не слышал, поэтому все равно сравниваем с MS SQL.

Вся фишка в том, как хранятся файлы в СУБД. У MS SQL вся база – два файла, если вы не занимаетесь секционированием, разбиением на table space и так далее.

Чаще всего – это просто два файла MDF и LDF. Все, там больше ничего нет.

Соответственно, на получение этой информации с СХД никакого времени не тратится.

А у PostgreSQL на каждое отношение каждый раз тратится дополнительное время – имя файла передать, служебную информацию передать и т.д…
Очень грубо это можно сравнить с ситуацией, когда вы копируете один файл в 10 ГБ по сети или 1000 файлов по 10 МБ, надеюсь все знают, какую разницу во времени этих операций вы получите.

Что такое отношение? Это не отношение 1С с PostgreSQL – и так понятно, что у них там любовь. Отношение в PostgreSQL – это табличка либо индекс, еще и разбитые по одному гигабайту. Этот один гигабайт вообще прошит через весь PostgreSQL красной нитью. И это решение, принятое 30 лет назад сейчас стало немного мешать, дальше расскажу где.

Получается, что наша великолепная база какого-нибудь «Управления холдингом», на MS SQL занимает 2 файлика и там на СХД все летает.

А если мы перешли на PostgreSQL, все тормозит, потому что там она будет занимать в районе 100 тысяч файлов. Там будет 11 тысяч табличек. Даже если каждая табличка в 1 гигабайт влезла, там будет 25 тысяч индексов примерно. Плюс на каждое отношение еще есть 2-3 служебных файлов у самого PostgreSQL.

Представьте, сколько служебной информации на каждый ваш запрос вам нужно поднять именно из СХД.

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

Загрузка из DT

Следующий момент – многопоточный DT, точнее многопоточная загрузка DT, которая появилась в платформе 8.3.19.

Казалось бы, при чем тут PostgreSQL? Но мы же с вами на секции Highload говорим о больших системах. А в больших системах прода без репликации не существует – в больших системах на PostgreSQL, по крайней мере точно. Плюс мы все с вами – или в мечтах пока, или в жизни – обладатели корпоративных лицензий 1С. Соответственно, у нас нет ограничения на 12 ядер сервера 1С.

Как работает многопоточная загрузка DT? Почему-то, по неизвестным мне причинам, в конфигураторе нам не дали этим управлять. И начиная с платформы 8.3.19, если ты просто пробуешь залить DT, потоков загрузки будет столько, сколько у вас ядер на сервере 1С.

В КОРПе ядер на сервер 1С не жалеют. Там и 80 бывает.

Но вот представьте, у вас DT начнет литься в 80 потоков. Это очень быстро. Но реальная скорость загрузки будет равняться скорости загрузки самой большой таблицы, которая у вас заливается, потому что все остальные 80 потоков всяко зальются. Из всех 11 тысяч таблиц в базе 1С 90% места занимают первые 20. Все остальные – это остальные 10%.

И, казалось бы, 1С прекрасно позаботилась о нас, но она не позаботилась о репликах PostgreSQL.

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

Несколько лет назад в среде PostgreSQL отказались от слова master и slave (главный и подчиненный). Теперь есть «master1» и «master2», чтобы админы не думали, что реплика slave – это что-то незначимое. Они должны относиться к ней как ко второму мастеру.

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

И все это потому, что кто-то взял и начал лить на мастер большой DT-шник.

Так происходит потому, что мастер пишет многопоточно – он так устроен. А реплика многопоточно писать не умеет. Она всегда пишет одним процессом, одним ядром. Вы ничего не сделаете, вы ее никак не заставите. Конечно там всё пишется очень оптимально, зависимость не прямая, но реплика точно отстанет от мастера и надолго.

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

Если у вас на сервере 1С 48 ядер, реплике на проигрывание того, что нагенерил мастер при заливке DT, понадобится примерно в 30 раз больше времени.

А вам понадобится примерно в 30 раз больше места под WAL-ы, чем при обычной работе. Это нужно учитывать.

Чтобы это учитывать, заливайте DT-шник из командной строки. Не из конфигуратора через «Загрузить информационную базу», а выполняете пакетный режим запуска конфигуратора, говорите залить DT-шник и там есть параметр jobs, выставляйте его в разумные значения, 4 скорее всего будет достаточно, с увеличением потоков реальная скорость загрузки навряд ли будет увеличиваться. Так как всё упрётся в больших таблицы, а каждая таблица льётся в один поток в любом случае.

Нас даже платформа 1С приучает к командной строчке)). Вы тут от PostgreSQL требуете визуализацию бэкапов, а вам 1С говорит – ничего не выйдет, вы даже DT-шник будете с командной строки загружать.

Зачем вы переливаете DT-шник? Вы явно с MS SQL поехали на PostgreSQL, другого смысла почти нет. Не с файловой же базы вы едете.

Так что зайдите в MS SQL, задайте отчет по верхним таблицам и посмотрите, что у вас там в лидерах по объёму. Вот сколько у вас лидеров таблиц, поделите это на два и примерно столько потоков задайте. Если у вас 10 таблиц, вы их будете лить в 5 потоков, у вас скорость заливки DT-шника будет аналогична скорости заливки двух больших таблиц.

Я очень много времени этому уделяю, потому что очень много кластеров PostgreSQL на этом моменте упали – и со слотами, и без слотов.

Без слотов у вас будет еще хуже – когда у вас нет слотов на мастере, у вас реплика без слотов, у вас произойдет следующее. Реплика с какой-то своей скоростью будет явно очень сильно отставать от мастера. У мастера нет слота, ему пофиг, отстает ли от него реплика, он начинает удалять WAL-ы, согласно вашему параметру max_wal_size.

Он достиг max_wal_size и начинает их удалять.

И когда реплика наконец-то прожует те WAL-ы, которые она закачала в себя, и наткнется на то, что нужный ей элемент WAL-а удален, она остановится. У вас будет точно такой же веерный отказ реплик, но мастер выживет.

Поэтому очень аккуратно. Кайфовая функция, но с ней нужно уметь работать.

Ограничение на один гигабайт

Следующий момент – это гигабайт, ещё одна «красная нитка» в PostgreSQL.

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

Я вас расстрою, эта проблема не только в таблице config. Этого можно добиться почти во всех таблицах. Попробуйте сформировать регламентированную отчетность в ФСС на 15 тысяч сотрудников. Если файлик xml будет занимать больше гигабайта – вы не сможете забэкапиться с pg_dump-ом.

Плюс вы не сможете сделать RESTORE.

Причем тут есть фишка:

• Когда вы бэкапитесь через pg_dump, он ругается на отсечку в один гигабайт.

• И при ресторе тоже ругается – правда на чуть меньше чем гигабайт, примерно на 950 мегабайт.

Это большая проблема.

Но тут на картинке не просто так две видеокарты GIGABYTE изображены, потому что в ноябре 2022 года Postgres Pro выпустил pg_dump, в котором реализован специальный параметр --enable-large-mem-buffers «Обрабатывать большие данные». Там это ограничение будет увеличено до 2 гигов. На MS SQL тоже 2, поэтому увеличивать до 4 или до 8 нет смысла. Вы в ячейку MS SQL больше двух гигов не положите, он вам не позволит – будет ругаться.

Наверное, это сначала въедет в Postgres Pro версии Enterprise, не знаю когда это дойдет до ванильной версии. Но когда-то, наверное, дойдет.

А вообще вам как 1С-разработчикам совет – начните уже использовать сжатое хранилище в 1С. Кладите данные в сжатое хранилище, а не просто так храните. Очень хорошо помогает.

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

Следующая тонкость – это temp_buffers и work_mem.

Сколько туда нужно поставить? Да поставьте хоть терабайты, просто вычислите эти параметры нормально.

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

Зачем вообще нужен temp_buffers и work_mem?

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

Work_mem нужен, чтобы операции order by и distinct делались в памяти, эти операции сопровождают все динамические списки.

Поэтому work_mem тоже не забывайте увеличивать.

В настройках выставьте log_temp_files=temp_buffers. И если у вас в логах будут появляться записи, что у вас TEMPORARY TABLE создана на диске, там будет указано еще и сколько туда байт всунули и какой оператор это вызвал. И вы поймете, если у вас очень много таких записей, вам надо temp_buffers увеличить или work_mem.

Это такая тонкость, на которую нужно обратить внимание.

AUTOVACUUM при INSERT

Следующий момент – AUTOVACUUM.

В 14 PostgreSQL AUTOVACUUM научился срабатывать при insert. Казалось бы, AUTOVACUUM – это пылесос. Он должен мне пропылесосить таблицу, когда я в ней что-то наудалял. А тут я же вставляю. Я вообще ничего не удаляю. Зачем мне AUTOVACUUM?

Когда вы навставляли данных, вам нужно, чтобы кто-то статистику посчитал.

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

Поэтому в 14-м PostgreSQL добавили параметры:

autovacuum_vacuum_insert_threshold = 1000

autovacuum_vacuum_insert_scale_factor = 0.2 -> 0.01

Теперь можно заставить AUTOVACUUM сработать при insert. Поправьте его умолчательное значение 20% на 1%, и будет работать намного лучше – он сам при insert будет вам обновлять статистику.

При этом ночная регламентная операция по статистике уходит на второй план.

Тонкости бэкапов

Ну и на закуску, самая большая тонкость эксплуатации PostgreSQL, как ни странно – это драка админов за то, как им бэкапы делать.

В PostgreSQL с бэкапами все совсем не так, как в MS SQL – настолько, что это требует перелома психики и всех знаний.

В целом у PostgreSQL есть два вида бэкапов – pg_dump и pg_probackup.

Я сюда не вывел pg_basebackup, потому что pg_probackup построен на pg_basebackup, т.е. он почти такой же, но pg_probackup по сравнению с pg_basebackup однозначно лучше.

Чем отличаются pg_dump и pg_probackup?

pg_dump:

• Самая кайфовая утилитка для маленьких баз. Все прекрасно. Ее самый главный плюс – она может дампить одну базу, как мы все привыкли в MS SQL.

• По просьбам 1С-ников в pg_dump можно сделать бэкап только нужных таблиц. Скоро там будут еще и запросы – вы сможете в нужных таблицах дампить только нужные данные через выборку, для среды разработки это будет очень полезно. А так вы можете дампить только нужные таблицы либо все, кроме ненужных. Например, зачем вам для среды разработки дампить из прода таблицу версионирования? Сдались вам эти 200 гигов. Просто в параметрах как исключение эту таблицу указываете, он вам схему таблицы сдампит, а данных там не будет. У вас и дамп будет быстрее, и рестрор быстрее. Это тоже огромный плюс pg_dump.

• Вам не нужно хранить архив WAL-ов. Это не плюс и не минус. Не нужно, потому что это бессмысленно – к дампу WAL-ы не подлить. Дамп самодостаточный. Это просто фулл бэкап.

• И то, что это – фулл бэкап, это минус. Всегда фулл, никаких дифференциальных бэкапов нет.

• Он реально долгий. Многопоточность, конечно, немного решает этот вопрос.

• Но вот по поводу многопоточности pg_dump у меня здесь сомневающаяся рожица. Почему она сомневается? У многопоточного дампа есть особенность, многопоточный дамп из коробки работает только для формата directoty -Fd. Это когда у вас дамп будет каждую табличку складывать в отдельный архив внутри каталога. Можно еще обмануть всех, лить дамп как SQL-текст и потом передавать в pgzip и там многопоточно сжимать. Но это уже не коробочное решение получается. Кроме этого, если мы в коробочном решении льем дамп многопоточно, то многопоточный дамп может пасть жертвой блокировок. У вас 11 тысяч таблиц, вы их начинаете сливать, и если при этом кто-то какую-то таблицу меняет, дамп просто останавливается. Этот момент можно поймать, даже если вы дампите с реплики, а в этот момент 1С-ники сделали структурное обновление на мастере. На реплику это все прилетело, у вас изменились таблицы, и дамп упал. Поэтому если вы дампите с реплики многопоточно через каталоги, вам придётся отключать реплику от мастера на время дампа и потом подключать обратно, это всё скриптуется.

Почти всех этих минусов лишен pg_probackup:

• Но у pg_probackup есть один большой минус – он всегда дампит целый кластер. Он нужен для резервного копирования всего кластера.

• pg_probackup нужен архив WAL-лов, если вы собираетесь откатываться на произвольный момент времени.

• У pg_probackup зато есть инкрементальный бэкап.

• Есть многопоточность.

• И есть совершенный иммунитет от проблемы одного гигабайта. Ему все равно, он работает с файлами, он не работает с вашими данными. Pg_dump читает данные и упаковывает, а pg_probackup просто файлы копирует.

• И когда pg_probackup работает инкрементально – это очень быстро. Если еще и через PTRACK – это еще быстрее.

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

У pg_restore почти такие же плюсы как у pg_dump:

• Можно ресторить одну базу. Можно в том же сервер, откуда взяли, рядом базу создать. Можно эту заменить – все, что хотите.

• При ресторе не нужны WAL-ы, рестор самодостаточный.

• pg_restore может производиться многопоточно для форматов pg_dump -Fc и _Fd

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

А у рестора через pg_probackup есть свои особенности:

• Многие думают, что раз через pg_probackup дампится весь кластер, то и восстановить можно только весь кластер. Нет, можно восстановить одну базу. Но у вас рядом все равно на новом порту будет восстановлен весь ваш кластер PostgreSQL, в котором будет только одна база. Файлы всех остальных ваших баз будут нулевого размера, а только у той базы, которую вы указали, файлы будут не нулевых размеров. И работать в этом кластере вы сможете только с этой базой. Боль в том, что это – отдельный кластер, ему нужно свои shared_buffers настроить, temp_buffers. Это отдельные ресурсы. Поэтому восстанавливать из pg_probackup с прода на разработческий контур и на контур тестирования больно и дорого, к сожалению. Там лучше pg_dump работает.

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

Вопросы

Есть ли особенность работы с индексами именно с точки зрения СУБД? Перестроить индекс, дефрагментировать индекс, ребилды. Например, у MS SQL только Enterprise версия умеет полностью на лету заменять и перерасчитывать индекс. Есть ли сложности в PostgreSQL?

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

Во-первых, дефрагментировать индексы в PostgreSQL вообще не надо. Ребилдить просто так их тоже не надо, этим никто не занимается – только если у вас проблема с индексом. Либо он ужасно распух и у вас упала скорость запросов из-за того, что он распух.

Так вот, в ванильном PostgreSQL есть команда – есть REINDEX CONCURRENTLY, это аналог перестройки индекса онлайн, доступной в MS SQL Enterprise.

Скажите, пожалуйста, что у ванильной версии PostgreSQL с 1С и кластеризацией? Хотя бы мастер – слейв. По нашему опыту – собрали, все прекрасно работает на других приложениях. Но платформа 1С 8.3.19 у нас час не могла понять, что у нее переехала нода. Один пинг потерян.

Это не к PostgreSQL. У вас речь о том, что мастер переключился на реплику, на второй мастер – привыкаем так называть, нет больше слейва. И вы в консоли поменяли имя сервера? Тут, к сожалению нет какого то единого инструмента для «прозрачного» переключения.

Нам проще в хосте сервера 1С заменить IP мастер-реплики сервера PostgreSQL. Когда у тебя мастер 1 выходит из строя, ты в хосте сервера 1С заменяешь IP на мастер 2. Оно сразу мгновенно работает, никаких проблем. И в 1С тоже ничего трогать не надо.
Кто-то делает это через HaProxy, кто-то через ngnix, кто-то через corosync и так далее. Вариантов много, каждый может подобрать себе тот, который его устроит больше всего.

Мы счастливые обладатели 1С:ERP, работаем на MS SQL, и еще у нас есть MES-система самописная на обычных формах. Два вопроса. Первый – стоит ли нам ERP пробовать уже на PostgreSQL? И второй вопрос – я слышал, что PostgreSQL с неуправляемыми приложениями, таким как наша MES-система, не очень дружит.

Первое. Стоит ли пробовать ERP? Пробовать точно стоит. Много ERP уже внедрено на PostgreSQL. Уже накоплены знания. Точно стоит пробовать. Это раз.

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

Вам надо перейти на управляемые блокировки, и все. И никакой больше особенности нет. Автоматические блокировки и PostgreSQL – несовместимые вещи. Совсем. Даже хуже, чем СХД.

Поэтому если она на автоматических блокировках, сначала переводите на управляемые. Делов два дня работы одного спеца. И все, у вас вся конфигурация будет на управляемых.

А дальше уже оптимизируйте запросы.

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

Статья написана по итогам доклада (видео), прочитанного на конференции  Infostart Event 2022 Saint Petersburg.