Здравствуйте, имеется проблема с отчетом по задачам. Раскопки привели к тому что в одной базе postgres составляет план запроса 1 в другой базе план другой. Что в итоге дает при равных условиях скорость формирования отчета в одной базе 2-3 сек, в другой 20-50 минут. Про влияние статистики в курсе, сбрасывал (в меделнной базе) - не помогло. Вопрос: Что еще может влиять и как исправить? могу предоставить скрины с планом отчета из pgadmin

(0) Конфиги то одинаковые?

+(1) Конфиги постгре и версии.

надо сбросить в быстрой а не в медленной. будет все медленно. у меня так было

А если быструю скопировать она остается быстрой или становится медленной?

Быстрая остается быстрой, быструю сделал сброс статистики - быстрая осталась быстрой (в ответ на(3).

(1) Одинаковые? они на одном сервере постгрес и 1с

enable_nestloop=off решит все проблемы

(7) Дай обниму)))) Вопрос снят, действительно не обратил внимание на параметр вложенных циклов.

(8) Не очень то радуйтесь, кое-где будет медленнее)

+(9) Но радикального тупизма не будет.

(7) ловите экстрасенса!

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

(12) Всё будет работать нормально. Просто постгрес начнет использовать нестед луп не когда попало, а только когда без него в принципе не обойтись.

Оптимизатор в постгресе чересчур оптимистичный, и очень часто занижает стоимость вложенных циклов. ОСОБЕННО, если используются подзапросы, а это в 1с сплошь и рядом.

(13) Спасибо за ответы и подсказки! Теперь все встало на свои места

(12) Так сами SQL запросы, генерируемые сервером приложений 1С для PostgreSQL для быстрой и медленной баз, одинаковые символ в символ, или все же есть какое-то различие?

(15) Абсолютно одинаковые, из одного дампа были подняты

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

(17) Эта багофича в постгресе проявилась сразу же, как только 1с начала его использовать. И за 10 лет так и не смогли радикально решить проблему.

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