В порядке эксперимента перевели базу 1С БП 2.0 с 8.2 файловой на 8.3.8 в связске с posttgres 9.4
стал тормозить самописный отчет.  в отчете идет соединение таблицы документов с оборотам регистра бухгалтерии
было
ВЫБРАТЬ
    ТоварныйЧекТовары.Ссылка КАК Документ,
    ТоварныйЧекТовары.Номенклатура КАК Номенклатура,
    СУММА(ТоварныйЧекТовары.Количество) КАК КоличествоПоДокументу,
    СУММА(ТоварныйЧекТовары.Сумма) КАК СуммаПоДокументу,
    ТоварныйЧекТовары.Номенклатура.Родитель.Наименование КАК ГруппаНоменклатуры
ПОМЕСТИТЬ ВремТовЧек
ИЗ
    Документ.ТоварныйЧек.Товары КАК ТоварныйЧекТовары
ГДЕ
    ТоварныйЧекТовары.Ссылка.Дата МЕЖДУ &НачДата И &КонДата
    И ТоварныйЧекТовары.Ссылка.Проведен = ИСТИНА
    И ТоварныйЧекТовары.Ссылка.СкладОтправитель = &Склад

СГРУППИРОВАТЬ ПО
    ТоварныйЧекТовары.Номенклатура,
    ТоварныйЧекТовары.Ссылка,
    ТоварныйЧекТовары.Номенклатура.Родитель.Наименование
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВремТовЧек.Документ,
    ВремТовЧек.Номенклатура,
    СУММА(ВремТовЧек.КоличествоПоДокументу) КАК КоличествоПоДокументу,
    СУММА(ВремТовЧек.СуммаПоДокументу) КАК СуммаПоДокументу,
    ВремТовЧек.ГруппаНоменклатуры,
    -СУММА(ЕСТЬNULL(ХозрасчетныйОборотыДтКт.СуммаОборот, 0)) КАК СтоимостьПартии,
    -СУММА(ЕСТЬNULL(ХозрасчетныйОборотыДтКт.КоличествоОборот, 0)) КАК КоличествоПоРегистру
ИЗ
    ВремТовЧек КАК ВремТовЧек
        ЛЕВОЕ СОЕДИНЕНИЕ


РегистрБухгалтерии.Хозрасчетный.Обороты(&НачДата, &КонДата, Регистратор, Счет В ИЕРАРХИИ (&Счет41), &ВидыСубконто, Организация = &Организация И Субконто2 = &Склад, КорСчет В ИЕРАРХИИ (&Счет41), &ВидыСубконто) КАК ХозрасчетныйОборотыДтКт
ХозрасчетныйОборотыДтКт
        ПО ВремТовЧек.Документ = ХозрасчетныйОборотыДтКт.Регистратор
            И ВремТовЧек.Номенклатура = ХозрасчетныйОборотыДтКт.Субконто1

СГРУППИРОВАТЬ ПО
    ВремТовЧек.Документ,
    ВремТовЧек.Номенклатура,
    ВремТовЧек.ГруппаНоменклатуры

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

Счет В ИЕРАРХИИ (&Счет41) замени на развернутый список

и нафига регситратор и обороты вместо отстатков???

на последней конференции инфостарта порекомендовали уходить от полного соединения. левое соединение нормально работает в postgres?

1С нормально работает только с MS SQL Server вот и весь ответ

(3) от _полного_ соединения надо уходить в объединение. потому что полное и левое - разные вещи. левое нормально работает в постгрес. просто запрос в (0) непонятный и нифига не простой.

помогло с условием на равенство счету.  почему так?))

(6) сравни два плана запроса и поймешь

(4) 1С всегда быстрее всего работает на файловой - вот это правильный ответ.
Любые сервера 1С и сервера БД это вынужденное и более тормозное решение когда много юзеров.
Чтобы пусть медленнее чем файловая но хотя бы работало а не висело как с файловой по сети.

(8) Имел радость многократно убедиться, что серверная версия работает быстрее файловой на одной и той же машине.

(9)+ уточнение: _некоторые_ операции/запросы работают быстрее.

(9) Хаха.

(10) А остальные коих больше, медленнее да? Забываем про оптимизацию сервера БД и работу с индексами с максимальным использованием памяти.

ЗЫ Оперативочку и прочие ресурсы давай ограничим и сравним?

(11) "на одной машине"

(12) я понял что на одной, но использовать ресурсы одной можно по разному в %

(0) запрос УГ;
файловая почти всегда будет быстрее на небольших данных и с 1м пользователем (да еще и без РЛС поди)
и тут уже без разницы какая СУБД

(0) ТС стоит понять простую вещь, что этот "тормозной запрос" в случае сервера будет практически одинаково "тормозить" на 1, 10 или 100 пользователях.
А в случае файловой даже 10 юзеров не дождутся ответа ))

(15)+ понятно что утрирую и практически разница будет (и возможно большая), но смысл такой примерно

PostgreSQL 9.5.4
https://postgrespro.ru/products/1c_build
То, что PostgreSQL обозначена как тестовая - сами разработчики говорят, что не страшно.
1С предлагается ставить 8.3.9 последний релиз.
https://postgrespro.ru/blog/company/129146

Правило номер раз - не делать джойнов с подзапросами или виртуальными таблицами.

(11) Надо постепенно переставать работать на старье 6-7-и летней давности...
Серверная индустрия сейчас предлагает такой огромный выбор всего и по вполне приемлемым ценам. Более того, в эту, казалось бы, консервативную область тоже проникла мода на новизну, как, например, в игровом сегменте, или же в айфонофилии. Еще не успела забыться реклама и славословие по поводу тех же E5-26XX v3, как уже трубят о скором пришествии новейших v4,v5 и т.д., которые "быстрее, выше, сильнее".
Политика сейчас такая - чтобы не тормозило, надо соответствовать тренду на обновление :)
и 1С держится в русле такой политики.

(19) Реклама и маркетинг ну никак не смогет перечеркнуть тот факт что развитие быстродействия процов вверх остановилось.
Сча идет развитие вширь, все больше ядер, все больше памяти (кэш и обычная) все больше юзеров.

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

(19)
+ удивляют 1С-ники, которые переводят на postgre, не задумываясь о дальнейшем обслуживании. Зато якобы экономят на стоимости MS SQL.

(0) У вас хоть кто-то знает postgre в организации?

(21) там и 1с не очень знают...

(20)+ И  в каждом обзоре новинок присутствует фраза "усовершенствована/оптимизирована внутренняя архитектура".
"Более подробный обзор мы начнем с логической структуры ядра Broadwell-EP, а затем коснемся оптимизаций конвейера в Broadwell по сравнению с предыдущей итерацией микроархитектуры Core и новых функциональных возможностей микропрограммы CPU." Отсюда https://servernews.ru/930831

Это не про 1-5 пользователей, это про тех кто создает здесь темы "Все тормозит!!!!" и потом, к сотому посту, выясняется, что база 150-200 ГБ, пользователей 150-300 и все что-то делают(себестоимость, тяжелые отчетыи т.д.). При этом "весьма мощный сервак"(с гордостью) представляет собой 2 Xeon-a E54xx-56xx, 8 ядер и "аж 32 GB оперативы". И еще водрузят туда 2 виртуалки для "повышения производительности"...

(4) мяхко говоря, это преувеличение, часто соответствующее практике.
Есть очень много примеров, когда сервера от мс убиты руками админов в полное УГ и кто тогда виноват? 1С? или не 1С?

(21) А мс скл много знают?! Вот прям все поголовно знают мс скл и умеют с ним работать, ага.

по существу заданного вопроса:
---
базу 1С БП 2.0 с 8.2 файловой на 8.3.8 в связске с posttgres 9.4
---
вся проблема в том, что БП2.0 на 8.2 в любом случае будет работать быстрее, чем на 8.3.8 в _серверном_ режиме с _любой_ СУБД. Тем более, если запрос написан в таком стиле, который на любом серверном режиме будет тормозить, поскольку он попадет с планировщик запросов и его производительность испортится.

(6) потому, что в иерархии каждый раз это подзапрос

(19) Кризис на дворе, какие там новые сервера. Сохранить бы то что есть..

(25) Количество 1с-ников, знающих MS SQL больше, чем Postgre.
Даже курсы есть у 1С по администрированию MS SQL.

(29) а тс и его сотоварищи на эти курсы уже сходили...

кстати, уверен на все 100%, что прошедшие сертификацию на администрирование мс скл вполне себе уверено себя чувствуют в общении с любой скл субд.

(28) Тем не менее, покупают http://www.cnews.ru/news/top/2016-09-30_rynok_serverov_v_rossii_vozobnovil_rost
"Большинство заказчиков прекрасно адаптировалось к современным экономическим условиям и в настоящее время совершает очень хорошо обдуманные точечные вложения в самую необходимую инфраструктуру с четким пониманием экономических оснований для введения в строй нового высокопроизводительного оборудования".

(29) у 1с видимо новые веяния, поэтому постгри в учебном курсе "Эксплуатация крупных информационных систем" уделяется не меньше внимания чем сиквелу. http://1c.ru/rus/partners/training/uc1/course.jsp?id=459

(31) Ну так и лексусы покупают..