Здравствуйте.
Поставил убунту 20 и на нее постгрес 11 от 1с. 1с сервер стоит на отдельной машине.
Все работает, но с ДИКИМИ тормозами, потому что htop показывает, что постгрес занял только одно ядро (из 40).
Как заставить его работать сразу в пределах одной сессии и процесса на большем количестве ядер?

(0) А памяти сколько сожрал?
Убунту 20 - это конечно фейл тот еще.

+(1) Я бы сделал так:
1) ОС - РЕД ОС
2) Постгре бы ставил прямо из редос - там есть сразу для 1С или наиболее свежий для 1С с postgrespro

+(2) Еще бы и курс взял - он копейки стоит https://uc1.1c.ru/course/administrirovanie-1s-predpriyatiya-na-linuks-na-primere-red-os-7-3-servernaya-i-klientskaya-chasti/

nestloop отключи. Тормоза станут менее дикими и более ручными.

(1) Памяти сожрано примерно 1.5 из 64. Сеть жрет... Ну около 50-100 килобайт в секунду при открытии документов.
А почему вдруг убунта 20 не подойдет? Вроде нормальная же. И в отличии от 22 постгрес ставится легко.
Про ред ос - я что-то не особо доверяю такой интересной операционке и новомодной операционке из сколково. Ну такое.

(5) Вы это имеете в виду?
https://manpages.ubuntu.com/manpages/xenial/man8/losetup.8.html
С сетью вроде как проблем нет, нагрузка нулевая. Если качать большие файлы, то скорость велика, 25-30 мегабайт (не мегабит).

(3) А еще - видеокурс по установке постгрес? Это как? Вот мы подводим курсор к иконке и жмем два раза?

(5) "новомодной операционке из сколково" - суровый "аргумент", конечно.
т.е., какбэ и рекомендации вендора не указ, раз не доверяешь?

(8) Можете ссылку кинуть?
https://its.1c.ru/db/v8317doc#bookmark:cs:TI000000254
Тут вот ни про какую ред ос не говорится, а про убунту вполне

(9) Не там смотришь
https://v8.1c.ru/tekhnologii/sistemnye-trebovaniya-1s-predpriyatiya-8/

+(10) https://v8.1c.ru/tekhnologii/postgrespro/

(10) На строчку выше этой чудной ред ос стоит та убунта, которая у  меня стоит.
И как смена операционки на соседнюю поможет настроить постгрес?

(10) (11) И где там прям рекомендации 1С относительно RED OS? Вижу только в списке поддерживаемых, нигде не вижу отдельных рекомендаций по ней.

(13) Читай внимательно (2) Специально для тебя выделю "Я бы сделал так:".

(14) У вас есть рабочий постгрес на этой оси? Можете кинуть его конфиг? Может я просто галку там не вписал наподобие "use_all_cores=true"?

(15) Нету. Сейчас перешел в другую компанию. Тут все на винде.
На предыдущей все крутилось на центоси. Но центось сейчас протухла и ближайший аналог из Российских вендоров - это redos. Ну и так я его пощупал - мне понравилось.
По поводу конфига - бери дистрибутив от postgrespro https://1c.postgres.ru/ . При инсталляции из их дистрибутива можно указать автоконфигурирование настроек. Он от твоего железа сконфигурирует. Этого обычно достаточно. По крайней мере заведется правильно, а тонкие настройки уже потом посмотришь.

(16) Переставил на этот дистрибутив. Никакой особой разницы не почувствовал.

seq_page_cost = 0.1
random_page_cost = 0.4
cpu_operator_cost = 0.00025

join_collapse_limit = 20
from_collapse_limit = 20

enable_mergejoin = off
synchronous_commit = off

(17) Вот же все разжевано
https://postgrespro.ru/docs/postgresql/14/config-setting
Выбирай свою версию PG и смотри. Там все расписано по конфигам.

(0) А с чего ты взял, что твои тормоза связаны именно с количеством ядер?

Насколько загружено это самое ядро в момент "тормозов"?

Сервер вертуальный?

(20) htop показывает все 40 ядер и при работе 1с загрузка одного (случайного) ядра 100%, остальные по нулям.

(21) Физический. Какой-то ксеон, 40 ядер, 2 проца, 64 га памяти. Диск - рейд5 на 6 дисков.

(19) Не вижу никакого подходящего параметра. Все накручено уже по максимуму у меня.

(0) Емнип одна сессия к постгресу порождает один бэкенд, который грузит одно ядро (с некоторым оговорками). Соотв. для большей утилизации cpu нужно несколько параллельных сессий

Тест Гилева сначала запусти.
Ну и не озвучена до сих пор версия платформы и версия совместимости конфигурации

И как накручено энергопотребление в биосе и ОС?

(26) Убунта 20 и постгрес 11. В начальном посте же написано.

(28) версия 1с

(29) Версия 8.3.17.1851.
1с сервер при подключении к этому постгресу работает криво (вернее, постгрес работает криво). Если подключиться к серверу mssql, то он начинает жрать все ядра и все с ним успешно проходит, то есть виноват скорее всего не сервер 1с.

(30) А кто сказал что работа на одном ядре это кривизна? Может так было задумано разработчиками. Всё-таки не надо от по сути студенческого курсовика ждать эффективности коммерческого продукта.

(30) Убунту шлак.
Если есть время то можно попробовать в винду воткнуть постгре и проверить производительность.
Мне кажется где то в самой ОС что то недокручено.

(31) В смысле почему 1с последних версиях смахивает на студенческий курсовик? Ну там не может паралелить запросы, идет на одном процессе на инстанцию и все такое?
Хороший вопрос.

(32) в нутрях у всех линуксов плюс минус одно и тоже

По факту только оболочка да формат пакетов разный

(33) у тебя не параллелятся запросы при однопользовательской или многопользовательской работе?

(32) Я вот тоже так думаю. Собственно я надеюсь, что мне скажут "леша, ну едрить тебя, впиши в конфиг use_all_cores = true и будет тебе счастье".

(36) Ну я ожидаю, что запрос от одного пользователя (через один сервер) будут работать на большем количестве ядер, чем одно. Пока такого нет.

max_parallel_workers
Чему равен

(39) max_parallel_workers=16
Остальные параметры, связанные с процессами, воркерами и прочим таким, я тоже либо оставил на 8-16, либо (для памяти) поставил размеры в гигабайты. Потребление памяти при работе - около 1.5 га на всю систему при рабочей базе.

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

(40) Значит, оптимизатор PostgreSQL не считает нужным что-либо параллелить, считает, что данный запрос целесообразнее выполнять в одном потоке.

(42) Как ему намекнуть, что надо паралелить?

Не думаю что от этого производительность прям вырастет.

(43) До 13-й редакции СУБД включительно, был параметр force_parallel_mode, в документации пишут - в основном для тестирования. В целом это нездоровая идея.
(44) Я тоже. Но у автора иные представления...

(33) Речь не об 1с, а о СУБД. Именно СУБД - многолетний студенческий курсовик. Просто эволюционировавший до состояния условной пригодности к эксплуатации. В постгресе есть ядро, которое вольно выбирать однопоточный или многопоточный алгоритм выполнения запроса. Ну и в вашем случае выбирает однопоточный. Это не баг, это особенность поведения.

(45) То есть думаете, что надо обновить до более новой базы, которая поддерживает постгре 14?

(46) Ок, постгре до 13 версии (к примеру) студенческий курсовик. А чего ее продают и рекомендуют в 1с, в постгрепро и так далее?

Ну так бесплатно же. А когда на бесплатном можно делать бабло - вообще круто.

Странно что вообще на 1 юзера ядро под 100% забивается. Обычно диск это слабое место. У тебя случайно рейд не програмный?

Случайно не на виртуалках все?

(50) А это вторая часть марлезонского балета. Оптимизатор постгреса не любит многопоточные алгоритмы и очень любит вложенные циклы (nested loop) при соединениях. Прямое следствие тезиса о студенческом курсовике, где главное чтобы зачет поставили)

(52) разве нестед луп жрет проц?
Диск же должен быть. Вот если бы хэш джойн какой

У 1с во фреше постгре и ниче работает

(53) Именно проц. Характерная для нестедлуп нагрузка - периодические пики на 100% загрузки одного ядра.
(54) А я и не говорю, что его нельзя настроить чтобы нормально работал. Суть в том, к постгресу должны прилагаться специалисты, способные провести тонкую настройку под конкретное аппаратно-программное окружение, с учетом характерной нагрузки. Там искусственный интеллект чаще вредит, чем помогает.

У 1Са есть вот такое в неисправленных ошибках: "При использовании СУБД POSTGRESQL при выполнении запросов с использованием IN наблюдается низкая производительность и повышенная нагрузка на оборудование из-за неоптимального плана запроса."

+(56) Исправили в тестовой 8.3.22.

(50) Нене, чистая убунта 20.04. Сервер hp dl160 g8, raid на основе smart array p420. Тесты прямой записи показывают скорость около 700 метров в секунду (на 2 секунды).

А можете скинуть конфиг вашего постгреса? Если не секретный секрет, конечно.

(57) Я не могу скачать тестовую 8.3.22 :(

(58) Что то очень древнее. Просто из любопытства гилевских попугаев сколько выдает?

(60) Я брал 11 версию, чтобы подходила под платформу 8.3.17.1852. В целом я уже отчаялся, может поставить 14 версию. И платформу обновить

(60) Данный тест не о чем лучше использовать тогда многопоточный тест производительности 1С fragster https://fragster.ru/

(61) У меня 8.3.17 работает на PostgrePro 14.4

(61) я про hp dl160 g8. Ему же 7-8 лет уже

(64) А, это. Ну и постгресу в целом то тоже не 2 месяца :) Диски там новые, памяти и процов много. Не вижу особо, зачем нужен новый сервер, если есть такой.

(47) 8.3.20 и 14.4 от 1С вполне неплохо.
Конфигурация, которая дико тормозит, какая? Обычные формы на автоматических блокировках с массой переписанного кода под MS SQL?

Для выяснения что тормозит, все тесты хороши. И Гилева, и Fragster-a и pgbench...

lscpu какую модель процессора показывает?

(65) Действительно, зачем!
А проц небось 1.8 ГГц на ядро? И диски наверное не ссд?

(38) а на других движках бд такое есть?

Создать несколько фоновых заданий,в каждом запросами что-то повыбирать и посмотреть,сколько будет занято ядер - по идее - должно быть столько,сколько фоновых.
Если это не так,то копать настройки,если это так,то про проблемы СУБД забыть.
Распараллеливание запросов - это очень сложный механизм,который чаще всего дает проигрыш по общей производительности.
Опять же,тормоза и т.п.стоит оценивать в каких-то более разумных тестах,т.к.некоторые старые конфигурации,в принципе,не жильцы.

RAID 5 - сильно тормозной для СУБД не годиться, посмотрите какая длина очереди диска.

Прогоните тест Гилева - он даст информацию по работе дисковой подистемы.

Диски хлам

если не SSD

(38) Не каждый запрос имеет смысл распараллеливать. Какой это отчет?

(68) Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz 2 штуки
Дисковое линейное чтение - 700 мегабайт в секунду. Нагрузки на диск нет когда проц сожран. ЧИтается несколько мегабайт и все.
Другие движки не пробовал, но попробовал поставить 11 постгрес на винду на соседнем компе - тормоза точно такие-же. mssql работает хорошо.

(74) Открыть список заказов (5 секунд и больше) - открыть заказ (еще 5 секунд) - открыть еще заказ (еще 5 секунд). Имеется в виду после нажатия на мышку и до открытия живого окошка.

(75) нужно не линейное чтение, а мин блоками. Обычно оно на хдд на порядки меньше

(77) Ну это понятно, но не нашел встроенной утилиты, чтоб прогнать такой тест.
Опять-же - судя по нагрузке на диск через iotop - не он узкое место.

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

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

(79) Чем отличается новомодный сервер купленный, за миллион сегодня от сервера, купленного 5 лет назад?
На оба ставим одинаковый линукс, одинаковый постгрес.

(79) Более того - я проверял дисковую подсистему. Она быстрая, на нее работы нет при работе постгреса. Чтение десятка мегабайт в течении секунды не дает никаких тормозов, даже при одном обычном хдд, а там стоит рейд5 на 6 дисков.

(82) "там стоит рейд5 на 6 дисков"
Безотносительно сабжа. Не очень вариант. Лучше если есть время и места хватает, переразбить в raid10.

(83) Я не вижу тут разницы между "дешманский вд купленный с рук", рейд 10 или рейд 5 с на 6 дисков сас (как у меня). Все они при нормальной работе обеспечивают скорость больше 50 мегабайт в секунду. А тут такой нагрузки нет, отсюда и вывод, что это не важно. Потом, когда одновременно 10 бухов будут полностью перепроводить базу весом в 10 гигов документов, тогда и будем думать, а сейчас в этом проблемы нет. Затык именно в однопоточности постгреса

(84) Да нет там никакой проблемы в однопоточности. Не даст тебе многопоточность такой прибавки какой ты ждешь. При многопоточности время на разбиение и потом синхронизацию результатов уходит. Ну будет при много потоке у тебя +5%, а возможно и -5%. Не там ты копаешь.

многопоточность дает выигрыш когда нужно тэйбл скан делать большой таблицы

но запросы с тэйбл скан сами по себе тормозные

(85) Ну если эту же базу присоединить с этим же сервером присоединить к mssql, то внезапно она наченает бодро бегать, а еще загружены много ядер, а не одно. Собственно вопрос - в чем отличие потсгреса от mssql? Очевидно в многопоточности.

а что за база? типовая? может там запросы, которые постгре не по силам?
из типовых долго выпиливали такое

(88) >>в чем отличие потсгреса от mssql? Очевидно в многопоточности
Это легко проверяется. В MS SQL принудительно запрещается многопоточность, 1С когда-то рекомендовала для улучшения работы.
Должно начать работать все плохо.

мсскл и потсгре отличается ... всем, а не только многопоточностью

видел как УТ10 переставили с МС на постгре. У части пользователей стали наблюдаться тормоза. Выяснили что тормозит из-за РЛС. Добавили индексацию в конфигураторе нужным объектам и всё залетало

рлс на постгре только производительный работает.
для этого его и писали

(88) Ну прям как тот анекдот про Чапаева, Петьку и таракана.

(76) Тут многопоточность не поможет. Скорее всего нужно настроить Постгрес.

В этом и есть главное отличие от MSSQL. Чтобы успешно эксплуатировать Постгрес, нужно в нем разбираться.

(92,93) В далекие времена, когда только появился 1С Документооброт и в него включили РЛС, то постгри умер от слова совсем. Все открывалось по 5 минут. Пришлось всем установить полные права, пока не купили МС. И на МС все залетало. Теперь любой постгри я обхожу стороной.

(96) А прикинь, в еще более далекие времена, самые первые SQL версии сливали DBF. По твоей логике нужно обходить SQL стороной.

(97) Куда они их сливали?

Я же говорил уже, причина не в многопоточности, а в нестедлупах по большим таблицах, которые почему-то оптимизатор постгреса считает маленькими. Оптимист блин.

(96) раньше - да, но времена то меняются

(100) Времена меняются, а осадок остался. На МС и сейчас все летает, РЛС визуально на скорость открытия форм не влияет совсем. Поэтому смысла с экспериментами по возвращению на постгри вообще не вижу. Быстрее мгновенного он все равно не откроет.

(0) Приведи тесты: "pgbench -v -p 5432 -c 10 -j 10 -t 10000 base"
предварительно создай базу base и наполни ее "pgbench -p 5532 -i -s 500 base"

(100) на постгре переходят не потому что он лучше, а потому что он дешевле

(101) ИМХО, пока в постгресе радикально не перепишут ядро, толку не будет. Самая главная проблема там - со сбором статистики в неявных временных таблицах, используемых при "селект фром селект". Эта статистика просто отсутствует, потому что запрос компилируется в самом начале, пока о фактических данных в этих временных таблицах ничего не известно. Поэтому "оптимистичный оптимизатор" предполагает, что они очень маленькие, и по ним можно эффективно гонять нестедлупы. Модуль "онлайн анализ" слегка решил проблему с _явными_ временными таблицами, но не с неявными..

а создание архивов они починили? помню была проблема - некорректный дамп базы после определенного объема на постгри

(0) вместо 11 ставь 13-й Pro - прирост будет

сейчас новый сервак по-всякому крутим, тестим
11-й сливает 13-му и под виндой и под линухами всякими, со стандартными настройками

а еще и конфиг подправили у 13-го, так получили разлет показателей минимум в 30%,
в некоторых тяжелых отчетах - время формирования отличается В НЕСКОЛЬКО РАЗ

(105) Сама 1С починила в платформе, стала разбивать на кусочки, не смотрел с какой версии но на 8.3.17 работает

(107) причем здесь 1с

(108) проблема была в том что в таблице config был элемент больше 1 гиг и он не выгружался нормально я об этом...

(109) ааа, спасибо. т.е. тулзы постгри все равно кривые

(107) Как-то смотрел старые архивы, в 8.3.5 уже было.
(110) Есть pg_dumpbinary. Правда, только для Linux.

(104) В мире PostgreSQL, видимо считают, что подобный подход достаточно неплох и просто предложат писать запросы и трансляторы из других сред более "оптимистично", а не разводить тягомотину из множества вложенных select и т.п.

Мне вот жалко, что 1с не работает с СУБД Firebird/Interbase. Легкая, мощная, удобная СУБД. Да, со своими тараканами типа однонаправленных индексов и ограничений на количество изменений структуры таблицы - но всё это легко можно обойти на уровне платформы 1с. А они почему-то чрезмерно усложненный и вечно сырой постгрес выбрали как альтернативу микрософту..

(113) 1. Почему Постгрес чрезмерно усложненный и вечно сырой?
2. Почему Firebird/Interbase легкая, мощная и удобная? И подходящая ли она для 1С?
3. Не напомнишь, в какой стране разрабатываются Firebird/Interbase и в какой Постгрес?

(113) и что фаерберд прожует запросы 1снве километровые?

(114) А что не так со странами? Интернациональная команда в обоих случаях. Русские и там и там есть. Вообще в России программисты традиционно к продуктам от борланда относятся с уважением.
Да и для конечного пользователя фб приятнее, одна база - один файл, никаких там кластеров с сотнями тысяч каталогов и файлов. Переносить, копировать базу fb/ib не сложнее чем в случае файловой базы. В отличие от постгреса, где в кластере потеряешься.
(115) Почему бы и нет?

(116) Я правильно понимаю, что по пунктам 1 и 2 ты ничего сказать не можешь, кроме своих очень ценных эмоций?

(116) По поводу стран намекаю, раз ты сам не сообразил, разработчик Постгрес — российская компания, в которой работают не только россияне, разработчик Постгрес — НЕ российская компания, в которой работают не только россияне
Дальше сообразишь?

(116) По поводу "программисты традиционно к продуктам от борланда относятся с уважением" в России много к каким IT-компаниям относятся/относились с уважением, что не помешало этим компаниям на фоне антироссийской истерии выкинуть совершенно ублюдочный финт ушами, выделив Россию в отдельно взятую страну, которой запрещается пользоваться их продуктами
Ну и нахрена нам эти бесконечно уважаемые компании?

(119) А борланд разве стал бесплатным? помню времена за рабочее место хотели 3-5к зеелнии

(120) Вроде Файрберд бесплатный, это вроде как форк Интербейса, при этом сам Интербейс тоже развивается, если верить https://www.ibase.ru/ibfbfeature/
Не стал про это писать, потому что лень писать, почему MS при его платности выбрали, причем основной СУБД, а тут типа почему нельзя

(102) Будет ли эффективно выводить отчет о результатах раз в 5523 секунд? Может срок поменьше поставить?

(122) 5523 это порт я ошибся в цифрах, нужно так
"pgbench -p 5432 -i -s 500 base"
порт можно не указывать тогда будет работать через unixsocks

(117) Очень ценные эмоции были, когда надо было срочно поднять базу постгреса на другом сервере в связи с отказом исходного. Этот кластер с синтетическими именами каталогов и файлов, где не поймешь что к какой базе относится, ощущение кучи мусора какой-то. Студенческий курсовик для демонстрации способностей студентов, который почему-то приглянулся 1с как заменитель платного mssql..

(124) из всех бесплатных - это самая мощная баз

(125) Вот только для массового сегмента нифига не подходящая. Ларьки, доросшие до клиент-сервера, не потянут поддержку и администрирование постгреса на нормальном уровне.

(126) так это и не для ларьков нужно было. сама 1с например на постгре сидит во фреше

(127) Ларьки воспринимают постгрес как возможность сэкономить вместо покупки mssql. Альтернативы по сути и нет, разве что бесплатная версия DB2, но в ней свои заморочки есть.

(118) Вообще это не правда. Разработчик Постгрес - это международное коммунити. Да, русская Postgres Professional вносит большой вклад, но без самого Постгресса они никто. Постгрес настолько же русский, насколько Firebird.

(128) ну сейчас уже вполне можно и ларьку. А у ТС наверняка РЛС старой версии

(130) Извините за глупый вопрос, но что такое РЛС?

(131) Row Level Security - функция в платформе 1с, когда к запросом на получения данных прицепляется некий подзапрос, ограничивающий доступ к данным в зависимости от прав пользователя.

(124) Как витиевато ты сказал "не осилил". Талант!

(128) Альтернатива сейчас это бесплатная версия MSSQL. Заморочек почти нет.

(134) пиратская (зачеркнуто) параллельно импортная ты хотел сказать

(134) Это вы про экспресс? Там ограничение на размер базы в 10 гигов. У людей и файловая больше бывает.

(136) Если больше, значит пора выходить из "ларьков" и платить. Либо за лицензию MSSQL, либо Postgres админу.

(137) в любом случае, еще 1ске забашлять, за серверную лицензию сверху)

(138) За нее уже заплатили раньше, когда перешли с файловой на Express.

(126) >Вот только для массового сегмента нифига не подходящая. Ларьки, доросшие до клиент-сервера, не потянут поддержку и администрирование постгреса на нормальном уровне.

можно было купить "форк" какой-нибудь версии постгри и довести ее до ума при помощи напильника и такой-то матери

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

(140) а как же быть с (138) ?) Всем желающим ознакомиться с 1с ее продавать за 80к, или сколько она сейчас стоит? Если у вас ТТ с одним рабочим местом, на кой там скульная версия? Да и облако может не подойти, например, косяк с инетом, а нужно инвентаризацию делать, да и смысл от этой абоненки, когда можно сэкономить, воткнув файловую версию?

(140) >можно было купить "форк" какой-нибудь версии постгри и довести ее до ума при помощи напильника и такой-то матери

Наивное заблуждение. Чтобы довести постгрю до уровня самообслуживания MSSQL, нужно вложить столько же человеко-часов, сколько вложила Microsoft. И даже больше, т.к. нужно поддерживать не одну ОС.

Все что можно было довести "малой кровью", они уже довели с Перконой. Эта версия скачивается с сайта 1С.

(141) одно рабочее место - велком ту облако

поддержка нищебродов через файловые костыли съедает слишком много ресурсов

(143) а кто ларьки с базовыми будет окучивать?

>Все что можно было довести "малой кровью", они уже довели с Перконой. Эта версия скачивается с сайта 1С.

так она с точки обслуживания и администрирование такое же уг как обычный постгри

(144) гребцы из франчевых галерных бараков

(142) постгре нельзя довести до уровня мсскл. ибо там разный подход.
мсскл - это ОС внутри ОС. а постгре таки опирается на механизмы ос

>Чтобы довести постгрю до уровня самообслуживания MSSQL, нужно вложить столько же человеко-часов, сколько вложила Microsoft.

извините, нифига не верю. ms потратило основные человеко-часы на конкуренцию с ораклом - версионник, сегментация, кластеризация и прочие ништяки

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

(147) Постгрес тормозит не поэтому. А я уже писал почему. Потому что студентам и их преподавателям пофиг на реальные профили нагрузки, они делали сферическую СУБД для некого идеального тестового профиля. Когда разработчики вдумчиво рисуют SQL-запросы ручками, а не когда некая система формирует их автоматически по метаданным, без учета особенностей СУБД.

(148) В последних версиях постгреса даже вменяемый pgadmin выкинули, вместо него какое-то джавовское убожище надо скачивать отдельно.

(149) ну так проблема 1с в том что она "формирует их .. без учета особенностей СУБД"

(148) К документации-то какие претензии? Документация на уровне имхо.

(149) О каких студентах ты говоришь? Постгре уже давно пилят другие люди.
(150) Ну так и в MSSQL консоль отдельно ставится.
(151) Да вроде последнее время, в релизах, оптимизации всякие к постгре описаны. Так что работают в этом плане.