После предыдущей задачи тестов на Db2 (неудачных), поставил себе задачу затестить 1с на PostgressPro. Поставить на Xubuntu - поставил, тут ума хватило! :) Там пошаговая инструкция, как его уставить и как сервис запустить. Но дальше совершенно не понимаю, что делать. На сайте PostgressPro инфы никакой нет. Я, к примеру, нашел - https://postgrespro.ru/docs/postgrespro/11/postgres-user - но тут нет инфы как создать(определить) пользователя базы данных, от имени которого потом будет подключаться сервер приложений.

Буду сильно признателен, если кто-то ставил  и  запускал и имеет представление, как это делать и может подсказать, куда посмотреть, скажем ссылкой на документацию

один мой клиент сначала взял 1С-ские лицензии DB2 взамен MSSQL,
а потом перешел на PostGreSQL :)

(1) да я вчера тестил db2, но все тесты прекратил сразу, как выяснил, что карточка 51го счета в ms sql открывается 25 секунд, а в db2 - 48. теперь хочу сравнить с psql, но вот знаний нет совершенно.

Нс ИС есть пара неплохих пошаговых инструкций

(2) >да я вчера тестил db2, но все тесты прекратил сразу, как выяснил, что карточка 51го счета в ms sql открывается 25 секунд, а в db2 - 48

А ты точно всё правильно сделал? Что сначала кэшь "разогревают" а потом тесты в курсе? Ты точно DB/2 оптимально настроил для 1с? Я вот такого опыта с DB/2 не имею и смогу сделать только дефолтовые настройки.
И да, с постгри аналогично - его нужно настроить согласно рекомендациям 1С (опять-же см ИТС), и кэшь разогреть.

(4) Спасибо  за учистие! Теперь ответы на вопросы:
"Ты точно DB/2 оптимально настроил для 1с?" - в отличии от других СУБД, DB2 "самонастраивает" сама себя при указании опции
db2set DB2_WORKLOAD=1C .

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

(0) Сделал проще. Написал в PostgresPro, попросил инструкций.

(0) "Я, к примеру, нашел - https://postgrespro.ru/docs/postgrespro/11/postgres-user - но тут нет инфы как создать(определить) пользователя базы данных, от имени которого потом будет подключаться сервер приложений"
Ну конечно, тебе надо сначала запустить сервер, и лишь потом внутри него ты сможешь создавать пользователя базы. Дальше - читай тут: https://postgrespro.ru/docs/postgrespro/11/client-authentication

(2) После того, как это чудо исполняло запрос при обновлении данных в БД после перехода на новую версию в течение 17 часов 35 минут там, где MS SQL хватило 2 минут - я эксперименты с PSQL забросил. Хотя местами он и опережал MS SQL процентов на 10-20. Ну нет у нас столько ресурсов, чтобы в боевой базе оперативно устранять подобные косяки. MS SQL стоит не так дорого на фоне затрат на содержание ИТ-специалистов, готовых круглосуточно исправлять тупняки.

(8) однако-ж! :(

(0) Все там есть...
https://postgrespro.ru/docs/postgresql/11/app-createuser

(8) >>  в течение 17 часов 35 минут
В каком году это было? В 2011-м, на сервере с 8ГБ памяти и 80-100 ГБ базой? Тогда такое вполне могло быть.
>>MS SQL стоит не так дорого на фоне затрат на содержание ИТ
Нет же никаких серьезных причин, чтобы самим не разобраться и изучить работу с PostgreSQL(а заодно и Linux), тем самым, сэкономив работодателю не одну сотню тысяч, а может, и миллион-полтора?

(11) 1. Было в 2018, на сервере с 64 Гб ОЗУ и базой на 30 Гб. Впрочем, ОЗУ там вообще не при делах было, ибо уперлось все в производительность 1 ядра (благо что частота этого 1 ядра была 5 ГГц).
2. Есть очень серьезная причина - ограниченное время. А сотни тысяч я регулярно экономлю - за счет отказа от услуг франчей, причем я экономлю не только за счет меньшей оплаты франчам, но и за счет экономии времени на совещания с франчем (что по сути на 90% - пустая болтовня и прикрытие собственной пятой точки) не самых дешевых топ-менеджеров. Разбираться с PSQL, с неясными перспективами, чтобы ВОЗМОЖНО сэкономить немного денег, а когда выяснится, что оно все равно тупит, и никакими настройками это не убирается - потратить еще кучу времени на разборки, установку самых свежих платформ с самыми свежими глюками, правку кривого кода типовой конфигурации и последующее поддержание этих правок при обновлении - не, спасибо, не надо.

(5) А вот можно подробнее насчет db2set DB2_WORKLOAD=1C.
Эта штука говорит СУБД сколько оперативной памяти можно использовать, как часто обслуживать статистику и т.д. и т.п.?

(13) И исправлять на лету бажные запросы от 1С...

(5) от кого-то из спецов (не помню, может Богачев) слышал что настройка DB/2 очень тонкая работа. Как-то сомневаюсь это "одной галочкой" всё решается.

(14) а ещё захватывает мир пока санитары не видят.

(5) Есть у постгри конечно моменты.... срез лучше во временную таблицу а не соединять сразу, с полным внешним соединением тоже не торт...  https://its.1c.ru/db/metod8dev#browse:13:-1:1981:1987

Может ваш запрос нужно переписать?

(11) Что за одержимость такая, экономить чужие деньги из альтруистических побуждений? Если работодатель с съэкономленных полутора лямов мне отпишет половину, то можно постараться, а иначе не вижу смысла экономить ему его бабло.

(17) Предлагаешь переписывать запросы типовых? Чтобы потом обновляться было интереснее? Чета не разделяю я такого интереса.

(19) Последние несколько лет(года 2-3) разработчики типовых сами неплохо с этим справляются. Этой зимой, в бухгалтерии для ГУ(старой, первой редакции), в одной из версий, стал зависать подбор ОС в инвентаризационной описи, именно на PostgreSQL. Поправили довольно быстро, за 2-3 недели. В сборке PostgrеSQL с 1c.releases.ru тоже регулярно оптимизируются различные моменты работы с 1С, судя п описанию изменений и дополнений. И ошибки исправляются ошибка в больничных листах ЗГУ
Так что, не все так плохо.
(18) Если что, в (11) присутствует легкая ирония )
Если руководство оценит труды, может, и будет какая-нибудь премия по итогам года.

(8) год назад перешли на пг с мс, потратили на настройку 2 дня, тупников все еще не обнаружено ???

(8)(12) Простите. Я просто поддержу автора постов. Ибо очень хорошо сказано. Пусть и не совсем верным тоном. ;-)

(8)(12) Да. И рекомендую к нему прислушаться. Сам имел такой же опыт.

(20) есть мнение, что не 2-3 а >= 4 лет/

(22) (23) ну давайте померяемся длиной... у нас на сиквеле осталась только упыпырка хоть и 1.3 но ооооочень старая ибо тупо влом и 1 нетленка (я хз по чему - возможно по недосмотру, может кто-то боится что одной упыпырки на СУБДшнике будет одиноко?), нагрузка пиковая на них 300 и 150 сеансов одновременно (включая фоновые). На постгри дофигища всего остального, включая 1С-Документооборот корп(пиковая >1000 сеансов, один раз их было примерно 1200, но совсем редко) и ещё 1 нетленку (пиковая 350 сеансов) и ещё дофига всего всякого.
Да все базя для разработки на PG.
Почему у нас всё нормально работает?

*базы

(25) потому, что "нормально" - понятие субъективное. цитируя классиков: "кому и кобыла - невеста"

(24) Не спорю, адаптация платформы и конфигураций к PostgreSQL развивалась постепенно, просто в 2010-2012 годах ждать исправлений можно было по полгода или дольше, да и сама СУБД(с патчами 1С) обновлялась не слишком часто, год-полтора, а теперь все гораздо быстрее. Уже 10.9-5.1С в актуальной версии, стараются не отставать от оригинальной версии. Хотелось бы уже 11-ю, но все что-то никак...

(27) ИБ работают интерактивно, время формирования отчётов/отработки обработок и т.п. всех устраивает (т.е. жалоб на низкую скорость нет). А у вас какие критерии нормы?

(29) ERP пробовал на PG? Чисто профессиональное любопытство.

(30) нет у нас ЕРП, а без эксплуатируемой базы достоверный тест потребует пару недель подготовки для теста (нагрузочного, по разным профилям нагрузки)... кто-ж мне эти пару недель даст!
PS пара недель это ещё оооочень оптимистичная оценка

(31) У нас тут скуль 2005-ой, он кривой, а так как покупали бандл, то апрегрейднуться нельзя до 2008-го. Покупать свежий - не дают финансирование. Встал вопрос перейти на PG свежий, а вроде как начиная с 10-го и 13-ой платформы, он очень быстрый. Но как бы это проверить?

(32) Накати на тест машину и посмотри, в чем проблема? На инфостарте какие=то ребята из пг про писали про свой опыт внедрения, можно поискать статью, там вроде было про ЕРП.

(33) >> в чем проблема?

Проблема в том как организовать проведение полноценного теста в условиях сопоставимых с реальными.
Способа только два:
1. Загнать всех пользователей на тестовую площадку и заставить повторить всё то, что они делают в продуктиве. В реальной жизни редко возможно. Большинству свою основную работу работать нужно и времени на дублирование тупо нет.
2. Замутить автоматизированные тесты. Это примерно пара месяцев работы специалиста, умеющего писать такие тесты, для того, чтобы покрыть тестами хотя бы 70-80%% используемого на предприятии функционала. Для покрытия всех 100% операций тестами писателю потребуется до полугода. А ещё тесты устаревают по мере изменения/обновления конфигурации.

А ещё есть проблема в оборудования для тестовой площадки. В конторе, где не дают денег на апгрейд СУБД, вряд ли легко найдутся средства на полноценный тестовый стенд.

(30) В справочнике «Внедренные решения» на сайте 1С есть некоторое количество внедренных решений ERP на PostgreSQL, от 40-150 рабочих мест. Наверное, людей устраивает.