Тестирую разные базы данных для перевода текущей файловой конфы на сервер предприятия. В отчетах часто юзается СрезПоследних(), скорость выполнения удручает.
Может кто-то сталкивался и нашел решение проблемы тормозов ?

Постгри на чем ???

(0) У постгресса серьезные проблемы оптимизации запросов в которых участвуют виртуальные таблицы. Соединения с ними просто ужасно тормозят.

Можно переделать

(1) win64, памяти 16, постгри последний с сайта 1С.

(2) +1

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

(3) Почти 100% не поможет.  Этой проблеме сто лет в обед...

Еще возможно можно подкрутить параметры оптимизации запросов в постгрессе... но стабильного результата врят-ли добъетесь.

(2) Как-то не айс переделывать запросы...
Потестим дб2, может он будет адекватнее.

(7) опыт показывает... что это не поможет.

(8) аа... тфу ты про db2..  про него не знаю

PS. Но знаю что часть движка связанная с постгресоом, db2 и ораклом тестируется и оптимизируется явно хуже мелкосовтовскгого и собственного

А что именно там тормозит ??? строится не оптимальный план выполнения ??? чей это косяк 1С или постгри ?

(10) трудно сказать... скорее всего оба виноваты...

(11) + у постгри хреновый оптимизатор... а 1С неудачно использует постгресс...

(12) у постгре нормальный оптимизатор, просто 1с не умеет юзать версионники

(10) любопытно что я читал рекомендации 1С по оптимизации запросов... там в том числе было неписано и то что я написал... причем без относительно к базе

(13) ну примерно так я и сказал

(14) потому что при хитрых объединениях анализатор может все равно накосячить с планом запроса

(16) согласен... просто с постгри это проявляется явнее

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

(18) да, и все это написано в тоненькой книжице "1с предприятие 8.1 клиент-сервер. особенности установки и использования". и про то, что полное соединение у постгре тупит, и про то, что сортировки значений NULL отличаются...

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

(3) Кстати насчет 64бита...
32битный сервер предприятия при выполнении запроса, результат которого превышает ~ 1G уходит в даун.
На MS SQL не повторял... только на postgress

(21) Сервер 1с 64 бит, а вот постгри 32, под винду на сайте 64 версии нет

(22) я про сервер 1С..  он усиленно кушал память при обработке запроса....

Тут вообще-то не 1C виновата (имеется в виду платформа), проблема состоит в том, что оптимизатор postgre не умеет вносить условия связи в подзапросы, а mssql умеет.

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

(24) вынести запрос к вирутальной таблице во временную - это ощутимо сложнее?

у 1С серьезные проблемы с реализацией периодических РС, нет альтернативы реализации

(25) я вообще-то имел в виду не это решение (не вынос во временную), но и это решение ощутимо усложняет код запроса по сравнению с простым соединением со срезом последних.