Добрый день!

Платформа 8.3.14.1565
Сервер SQL Postgresql 10
Есть запрос с левым соединением по измерению регистра


"ВЫБРАТЬ РАЗРЕШЕННЫЕ
        |    ЕСТЬNULL(КВП_СведенияОПроживающихНаДату.Жилец, КВП_СведенияОПроживающихНаДатуБезОтбора.Жилец) КАК Проживающий,
        |    ЕСТЬNULL(КВП_СведенияОПроживающихНаДату.Жилец.ФизЛицо, КВП_СведенияОПроживающихНаДатуБезОтбора.Жилец.ФизЛицо) КАК ФизЛицо,
        |    ЕСТЬNULL(КВП_СведенияОПроживающихНаДату.ЛицевойСчет, КВП_СведенияОПроживающихНаДатуБезОтбора.ЛицевойСчет) КАК ЛицевойСчет,
        |    ЕСТЬNULL(КВП_СведенияОПроживающихНаДату.ЛицевойСчет.Адрес.Владелец, КВП_СведенияОПроживающихНаДатуБезОтбора.ЛицевойСчет.Адрес.Владелец) КАК Здание,
        |    ЕСТЬNULL(КВП_СведенияОПроживающихНаДату.ЛицевойСчет.Адрес, КВП_СведенияОПроживающихНаДатуБезОтбора.ЛицевойСчет.Адрес) КАК Квартира,
        |    КВП_СведенияОПроживающихНаДату.ДатаИзменения КАК ДатаПрибытия,
        |    ВЫБОР
        |        КОГДА КВП_СведенияОПроживающихНаДату.ДатаИзменения < КВП_СведенияОПроживающихНаДатуБезОтбора.ДатаИзменения
        |            ТОГДА КВП_СведенияОПроживающихНаДатуБезОтбора.ДатаИзменения
        |    КОНЕЦ КАК ДатаВыбытия,
        |    ИСТИНА КАК Проживает
        |ПОМЕСТИТЬ втПроживающих
        |ИЗ
        |    РегистрСведений.УПЖКХ_СведенияОПроживающих.СрезПоследних(
        |            &Период,
        |            Проживает
        |                И ДатаИзменения <= &Период) КАК КВП_СведенияОПроживающихНаДату
        |        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.УПЖКХ_СведенияОПроживающих.СрезПоследних(&Период, НЕ Проживает) КАК КВП_СведенияОПроживающихНаДатуБезОтбора
        |        ПО (КВП_СведенияОПроживающихНаДатуБезОтбора.Жилец = КВП_СведенияОПроживающихНаДату.Жилец)
        |;"



Запрос наглухо виснет в базе на postgresql.
В файловой формируется за 10 сек
В MS SQL тоже.

postgresql настроен по всем канонам. Поле "Жилец" индексируется.

Разработчики конфигурации уже 2 неделю анализируют базу или говорят, что анализируют(
Помогите, у меня уже варианты закончились.

А постгри запатчен патчем для 1С ? У меня ничего не зваисает. Давно сижу на постгри. Правда патч на 9,6 верисю. Судя по версии твего постгри он не запатчен

(1) А вот об этом я не подумал...
На сайте postgre рекомендуют 9.4.14 и 9.6.5.
Щас попробуем, спасибо за наводку.

Обязательно отпишись.

(0) вообще в "типичных причинах неоптимальной работы запросов" на ИТС как раз написано про соединение с виртуальными таблицами.
Так что как вариант - поместить каждую виртуальную во временную, и лишь потом соединять.

(1) на 10-ую патч уже не нужен, насколько я знаю. там сделано через расширение.

(5) откуда ставил постгре? Ставь из репозитория postgrespro.ru

+ (6) https://postgrespro.ru/products/1c/supported

(0) Перепишите запрос на пакет и ипите мозг.

> Разработчики конфигурации уже 2 неделю анализируют базу или говорят, что анализируют

Они-то как раз ипут вам мозг. Это очевидно.

(0) Для начала можно прост избавиться от ошибок в виде сравнения даты с NULL.
Типа КВП_СведенияОПроживающихНаДату.ДатаИзменения < КВП_СведенияОПроживающихНаДатуБезОтбора.ДатаИзменения.

Вообще вот это поле (ниже) - оно что? Каков его смысл? Что там должно быть, если условие в КОГДА не выполняется? Почему нет ИНАЧЕ?

|ВЫБОР
|        КОГДА КВП_СведенияОПроживающихНаДату.ДатаИзменения < КВП_СведенияОПроживающихНаДатуБезОтбора.ДатаИзменения
|            ТОГДА КВП_СведенияОПроживающихНаДатуБезОтбора.ДатаИзменения
|    КОНЕЦ КАК ДатаВыбытия

+ к (9) Вообще авторы текста запроса из (0) в курсе что такое правое и левое соединение и чем они отличаются? В тексте явно перепутаны право и лево.

(8)* "и ипите" читать как "и НЕ ипите"

Извиняюсь.

(9) Да сам отчет в конкретном случае я переписал. Но проблема в том что в типовом решении они используют такой отбор проживающих везде где нужно получить таблицу проживающих, там не правильная логика еще и самого регистра. И в самом первом обращении к разработчикам я указывал конкретно на этот кривой запрос, а они еще чето анализируют. Просто переписывать пол конфы из-за "крутых" разработчиков.
Кстати запрос вывел информацию спустя 57 596 сек, в файловой базе выводит за 18 сек.

Моё любимое "enable_nestloop=off" в очередной раз

(13) включал выключал - без результата, делал индексацию, чистил мусор.

ВЫБРАТЬ РАЗРЕШЕННЫЕ X СрезПоследних Х КВП_СведенияОПроживающихНаДату.ЛицевойСчет.Адрес.Владелец
вам самим то не жалко его?

(9) Спасибо и за эту наводку
Кстати оптимизированный запрос, выводиться за 8 сек)))

ВЫБРАТЬ
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец КАК Жилец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец.ФизЛицо КАК ЖилецФизЛицо,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет КАК ЛицевойСчет,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес.Владелец КАК ЛицевойСчетАдресВладелец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес КАК ЛицевойСчетАдрес,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ДатаИзменения КАК ДатаИзменения
ПОМЕСТИТЬ СОтбором
ИЗ
    РегистрСведений.УПЖКХ_СведенияОПроживающих.СрезПоследних(
            &Период,
            Проживает
                И ДатаИзменения <= &Период) КАК УПЖКХ_СведенияОПроживающихСрезПоследних
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец КАК Жилец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец.ФизЛицо КАК ЖилецФизЛицо,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет КАК ЛицевойСчет,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес.Владелец КАК ЛицевойСчетАдресВладелец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес КАК ЛицевойСчетАдрес,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ДатаИзменения КАК ДатаИзменения
ПОМЕСТИТЬ БезОтбора
ИЗ
    РегистрСведений.УПЖКХ_СведенияОПроживающих.СрезПоследних(&Период, НЕ Проживает) КАК УПЖКХ_СведенияОПроживающихСрезПоследних
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ЕСТЬNULL(СОтбором.Жилец, БезОтбора.Жилец) КАК Проживающий,
    ЕСТЬNULL(СОтбором.Жилец.ФизЛицо, БезОтбора.Жилец.ФизЛицо) КАК ФизЛицо,
    ЕСТЬNULL(СОтбором.ЛицевойСчет, БезОтбора.ЛицевойСчет) КАК ЛицевойСчет,
    ЕСТЬNULL(СОтбором.ЛицевойСчет.Адрес.Владелец, БезОтбора.ЛицевойСчет.Адрес.Владелец) КАК Здание,
    ЕСТЬNULL(СОтбором.ЛицевойСчет.Адрес, БезОтбора.ЛицевойСчет.Адрес) КАК Квартира,
    СОтбором.ДатаИзменения КАК ДатаПрибытия,
    ВЫБОР
        КОГДА СОтбором.ДатаИзменения < БезОтбора.ДатаИзменения
            ТОГДА БезОтбора.ДатаИзменения
    КОНЕЦ КАК ДатаВыбытия,
    ИСТИНА КАК Проживает
ИЗ
    СОтбором КАК СОтбором
        ЛЕВОЕ СОЕДИНЕНИЕ БезОтбора КАК БезОтбора
        ПО (БезОтбора.Жилец = СОтбором.Жилец)


А вот так за 6 сек.

ВЫБРАТЬ
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец КАК Жилец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец.ФизЛицо КАК ЖилецФизЛицо,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет КАК ЛицевойСчет,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес.Владелец КАК ЛицевойСчетАдресВладелец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес КАК ЛицевойСчетАдрес,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ДатаИзменения КАК ДатаИзменения
ПОМЕСТИТЬ СОтбором
ИЗ
    РегистрСведений.УПЖКХ_СведенияОПроживающих.СрезПоследних(
            &Период,
            Проживает
                И ДатаИзменения <= &Период) КАК УПЖКХ_СведенияОПроживающихСрезПоследних
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец КАК Жилец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец.ФизЛицо КАК ЖилецФизЛицо,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет КАК ЛицевойСчет,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес.Владелец КАК ЛицевойСчетАдресВладелец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес КАК ЛицевойСчетАдрес,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ДатаИзменения КАК ДатаИзменения
ПОМЕСТИТЬ БезОтбора
ИЗ
    РегистрСведений.УПЖКХ_СведенияОПроживающих.СрезПоследних(&Период, НЕ Проживает) КАК УПЖКХ_СведенияОПроживающихСрезПоследних
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ЕСТЬNULL(СОтбором.Жилец, БезОтбора.Жилец) КАК Проживающий,
    ЕСТЬNULL(СОтбором.Жилец.ФизЛицо, БезОтбора.Жилец.ФизЛицо) КАК ФизЛицо,
    ЕСТЬNULL(СОтбором.ЛицевойСчет, БезОтбора.ЛицевойСчет) КАК ЛицевойСчет,
    ЕСТЬNULL(СОтбором.ЛицевойСчет.Адрес.Владелец, БезОтбора.ЛицевойСчет.Адрес.Владелец) КАК Здание,
    ЕСТЬNULL(СОтбором.ЛицевойСчет.Адрес, БезОтбора.ЛицевойСчет.Адрес) КАК Квартира,
    СОтбором.ДатаИзменения КАК ДатаПрибытия,
    ВЫБОР
        КОГДА СОтбором.ДатаИзменения < БезОтбора.ДатаИзменения
            ТОГДА БезОтбора.ДатаИзменения
        ИНАЧЕ ДАТАВРЕМЯ(1, 1, 1, 1, 1, 1)
    КОНЕЦ КАК ДатаВыбытия,
    ИСТИНА КАК Проживает
ИЗ
    СОтбором КАК СОтбором
        ЛЕВОЕ СОЕДИНЕНИЕ БезОтбора КАК БезОтбора
        ПО БезОтбора.Жилец = СОтбором.Жилец


что мешает использовать вместо ЕСТЬNULL(СОтбором.ЛицевойСчет.Адрес.Владелец, БезОтбора.ЛицевойСчет.Адрес.Владелец) КАК Здание ЕСТЬNULL(СОтбором.ЛицевойСчетАдресВладелец, БезОтбора.ЛицевойСчетАдресВладелец) КАК Здание ?????

еще и на левое

(18) ничего, здесь просто были заменены таблицы регистров на временные, итоговый запрос не менялся

(20) не понимаете да?

(21) понимаю, я так и переделал, изначально это место сформировалось конструктором при замене таблицы регистра на временную

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

В итоге имеем время вывода 3 сек.
Всем спасибо!)

ВЫБРАТЬ
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец КАК Жилец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец.ФизЛицо КАК ЖилецФизЛицо,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет КАК ЛицевойСчет,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес.Владелец КАК ЛицевойСчетАдресВладелец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес КАК ЛицевойСчетАдрес,
    ЕСТЬNULL(УПЖКХ_СведенияОПроживающихСрезПоследних.ДатаИзменения, ДАТАВРЕМЯ(1, 1, 1, 0, 0, 0)) КАК ДатаИзменения
ПОМЕСТИТЬ СОтбором
ИЗ
    РегистрСведений.УПЖКХ_СведенияОПроживающих.СрезПоследних(
            &Период,
            Проживает
                И ДатаИзменения <= &Период) КАК УПЖКХ_СведенияОПроживающихСрезПоследних
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец КАК Жилец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.Жилец.ФизЛицо КАК ЖилецФизЛицо,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет КАК ЛицевойСчет,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес.Владелец КАК ЛицевойСчетАдресВладелец,
    УПЖКХ_СведенияОПроживающихСрезПоследних.ЛицевойСчет.Адрес КАК ЛицевойСчетАдрес,
    ЕСТЬNULL(УПЖКХ_СведенияОПроживающихСрезПоследних.ДатаИзменения, ДАТАВРЕМЯ(1, 1, 1, 0, 0, 0)) КАК ДатаИзменения
ПОМЕСТИТЬ БезОтбора
ИЗ
    РегистрСведений.УПЖКХ_СведенияОПроживающих.СрезПоследних(&Период, НЕ Проживает) КАК УПЖКХ_СведенияОПроживающихСрезПоследних
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗРЕШЕННЫЕ
    ЕСТЬNULL(СОтбором.Жилец, БезОтбора.Жилец) КАК Проживающий,
    ЕСТЬNULL(СОтбором.ЖилецФизЛицо, БезОтбора.ЖилецФизЛицо) КАК ФизЛицо,
    ЕСТЬNULL(СОтбором.ЛицевойСчет, БезОтбора.ЛицевойСчет) КАК ЛицевойСчет,
    ЕСТЬNULL(СОтбором.ЛицевойСчетАдресВладелец, БезОтбора.ЛицевойСчетАдресВладелец) КАК Здание,
    ЕСТЬNULL(СОтбором.ЛицевойСчетАдрес, БезОтбора.ЛицевойСчетАдрес) КАК Квартира,
    СОтбором.ДатаИзменения КАК ДатаПрибытия,
    ВЫБОР
        КОГДА СОтбором.ДатаИзменения < БезОтбора.ДатаИзменения
            ТОГДА БезОтбора.ДатаИзменения
        ИНАЧЕ ДАТАВРЕМЯ(1, 1, 1, 0, 0, 0)
    КОНЕЦ КАК ДатаВыбытия,
    ИСТИНА КАК Проживает
ПОМЕСТИТЬ втПроживающих
ИЗ
    СОтбором КАК СОтбором
        ЛЕВОЕ СОЕДИНЕНИЕ БезОтбора КАК БезОтбора
        ПО (БезОтбора.Жилец = СОтбором.Жилец)
;



осталось с нул порешать, есть он или кушать

В итоге больше всего нравиться ответ разработчиков.
Выглядело это примерно так:

07.03-Я- У нас не формируется отчет, проблема в запросе вот в этом месте.
07.03-Р-У нас все работает на релизе "таком то", обновите конфигурацию
07.03-Я- релиза "такого -то" нет на оф. сайте
07.03-Р- это тестовый релиз, вот вам ссылка
07.03-Я- Обновили проблема сохранилась
11.03-Р- Дайте копию базы
11.03-Я- Вот ссылка
12.03-Я- Есть результат?
12.03-Р- база анализируется
13.03-Я- есть результат?
14.03-Р- данные анализируются
15.03-Я- есть результат?
15.03-Р- база тестируется
19.03-Я- Есть результат?Сроки?
20.03-Р- тестируется сроки назвать не можем
22.03-Я- Мы решили проблему своими силами
22.03-Р- Вчера вопрос был передан в отдел разработки на рассмотрение
22.03-Я(В шоке)- а что вы делали до этого?
22.03-Р- до этого момента проблема анализировалась линией консультации. Как будет ответ мы вам сообщим.

Занавес.

(26) В среднем две недели приходится бодаться с линией консультаций, чтобы они наконец-то признали ошибку ошибкой и передали на рассмотрение разработчиком. Это норма для 1с.

(26) Купите корпоративную поддержку и к Вашим проблемам будут относиться уважительнее (С)

(24) Еще бы сравнить это оптимизированый код, с файловой и MS SQL.

(29) В этом, думаю, особого смысла нет. Результат сравнения больше будет зависеть не от конкретной СУБД, а от различных прочих условий (общий размер данных, размер данных попадающих в отбор и пр.).
В особенности если верить автору ветки в (12): "там не правильная логика еще и самого регистра". И судя по самому запросу, я склонен с ним согласиться.

(29) в среднем, во всех вариантах, время выполнения 3-5 сек.

(12) если это та конфа о которой я думаю, то там в регистре накопления УПЖКХ_Начисления - есть измерение Количество, я так и не разобрался зачем)

(32) да-да есть такое) использование нигде не встречается, может код в защищенных обработках)

(33) Ну пару раз при написании собственных квитанций, я натыкался на то что количество сворачивалось, а не суммировалось. И каждый раз с криком на весь отдел "Количество же измерение" задача решалась.
А так да, в старых релизах в зашифрованных модулях.

АП

Еще хотел написать, если нужно использовать запрос к виртуальной таблице(пример "Срез последних") с пост условием 100 раз подумайте использовать ли такой механизм в postgre.

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


ВЫБРАТЬ
    КВП_НазначенныеНачисленияСрезПоследних.Объект КАК Объект,
    КВП_НазначенныеНачисленияСрезПоследних.Услуга КАК Услуга
ПОМЕСТИТЬ НазначенныеНачисления
ИЗ
    РегистрСведений.КВП_НазначенныеНачисления.СрезПоследних(&ДатаСреза, ) КАК КВП_НазначенныеНачисленияСрезПоследних
ГДЕ
    КВП_НазначенныеНачисленияСрезПоследних.Действует= ИСТИНА



Время выполнения запроса 870 сек. понятное дело что в отчете его особо не используешь.

Дай думаю переделаю запрос без ВТ, сделал следующее


ВЫБРАТЬ
    КВП_НазначенныеНачисления.Объект КАК Объект,
    КВП_НазначенныеНачисления.Услуга КАК Услуга,
    МАКСИМУМ(КВП_НазначенныеНачисления.Период) КАК Период
ПОМЕСТИТЬ ВсеНачисления
ИЗ
    РегистрСведений.КВП_НазначенныеНачисления КАК КВП_НазначенныеНачисления
ГДЕ
    КВП_НазначенныеНачисления.Период <= &ДатаНачала

СГРУППИРОВАТЬ ПО
    КВП_НазначенныеНачисления.Объект,
    КВП_НазначенныеНачисления.Услуга
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    КВП_НазначенныеНачисления.Услуга КАК Услуга,
    КВП_НазначенныеНачисления.Объект КАК Объект

ИЗ
    ВсеНачисления КАК ВсеНачисления
        ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КВП_НазначенныеНачисления КАК КВП_НазначенныеНачисления
        ПО ВсеНачисления.Объект = КВП_НазначенныеНачисления.Объект
            И ВсеНачисления.Услуга = КВП_НазначенныеНачисления.Услуга
            И ВсеНачисления.Период = КВП_НазначенныеНачисления.Период
ГДЕ
    КВП_НазначенныеНачисления.Действует = ИСТИНА
;





В итоге время выполнения 0,943 сек.

в общем -не перестаю удивляться)

(35) При реализации среза последних самостоятельно нужно не забывать про "Активность".

(36) точно, спасибо за наводку