Добрый день!
В клиент-серверном варианте возникла проблема: не формируется "Справка-расчёт амортизации". В файловом варианте и при использовании MS SQL 2008 - всё нормально. Сервер Postgresql настроен по вот этой статье - https://its.1c.ru/db/metod8dev/content/5866/hdoc/_top/postgresql
Мониторинг с сервером Postgresql показывает, что сам постгрес что-то колбасит, отжирая ядро, но ввода-вывода практически не создаёт.

Сервер 1с: 8.3.8.2027 x86_64
Сервер баз данных: Postgresql 9.4.2-1c на Debian x86_64/

ах да, конфа - "Бухгалтерия сельхозпредприятия"

enable_nestloop=off в постгре попробуй

(2) спасибо, сработало) но я тут в соседней ветке набрёл на обсуждение этой опции и всё не так гладко) буду копать дальше)

(3) Всё там гладко. Просто отключаешь тупой алгоритм и заставляешь пользоваться умным. Умный может быть слегка медленнее в некоторых случаях, но тупой тупит намного сильнее. Это как пузырьковая сортировка против быстрой.

>>Сейчас я вышел из этого положения так - нашел самого смышленого бухгалтера, написал ей инструкцию как включать и выключать enable_nestloop когда надо формировать ведомость амортизации. Но все это как-то не красиво ...
v8: PostgreSQL, документы с большим количество проводок и ведомость амортизации

(5) ужас какой

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

random_page_cost = 1.5-2.0 для RAID, 1.1-1.3 для SSD

Стоимость чтения рандомной страницы (по-умолчанию 4). Чем меньше seek time дисковой системы тем меньше (но > 1.0) должен быть этот параметр. Излишне большое значение параметра увеличивает склонность PgSQL к выбору планов с сканированием всей таблицы (PgSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). И это плохо.

(7) Нюанс в том, что нестед луп вообще не нагружает дисковую подсистему, а пилит процессорные ядра вложенными циклами над закэшированными данными..

И чо делать? На форумах пишут, что нестид луп отключать нельзя.

(8) та же фигня только с rls БСПшный, динамические списки с rls тупят ппц (

(9) На форумах многое пишут. Но факт остается фактом - в случае характерных для 1с джойнов с многоэтажными запросами его лучше отключать.

(11) В БГУ 1.0 года 3 уже как такие запросы подправили, та же ведомость ОС и НМА и ведомость амортизации формируются секунд за 50-60 с enable_nestloop=on. Правда, с выключенным  - за 4-5 сек... А с главной книгой ровно наоборот, enable_nestloop=on хорошо помогает.
Может, у автора темы конфа не обновлялась. Или ее разработчики не обновляли.

(12) Проще всего - перейти на бесплатный sql2008 r2 express, если объем данных позволяет - у него оптимизатор запросов более умный.

(13) Если заменить Debian на платный Windows Server, то - да.

(14) XP достаточно или там семерки

Разрабы слона вроде на 50 русские.
Чт они говорят на эту тему.

попробовать на 8.3.9 или последней 8.3.8 что-то для ЗУПа + потсгре как раз пилилось там

(5) с 2010 года прошло некоторое количество времени