Сколько записей возвращает этот запрос?

kirill

SELECT COUNT(T1._Q_000_F_000RRef), SUM(CASE WHEN (T2.Fld1697RRef IS NOT NULL) AND (T2.Fld1697RRef IN ('\\217\\242\\332o\\343\\334\\252P\\021\\353\\310\\362\\031\\210\\330\\023'::bytea, '\\217\\242\\332o\\343\\334\\252P\\021\\353\\310\\362\\031\\210\\330\\026'::bytea)) THEN CAST(1 AS NUMERIC) ELSE CAST(0 AS NUMERIC) END), SUM(CASE WHEN (T1._Q_000_F_000RRef IN ('\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000\\000'::bytea)) THEN CAST(1 AS NUMERIC) ELSE CAST(0 AS NUMERIC) END), SUM(CASE WHEN (T2.Fld1697RRef IS NOT NULL) AND (NOT (((T2.Fld1697RRef IN ('\\217\\242\\332o\\343\\334\\252P\\021\\353\\310\\362\\031\\210\\330\\023'::bytea, '\\217\\242\\332o\\343\\334\\252P\\021\\353\\310\\362\\031\\210\\330\\026'::bytea))))) THEN CAST(1 AS NUMERIC) ELSE CAST(0 AS NUMERIC) END) FROM TEMPTABLE T1 LEFT OUTER JOIN (SELECT T3._Fld1696RRef AS Fld1696RRef, T3._Fld1697RRef AS Fld1697RRef FROM _InfoRgSL2446 T3 WHERE (T3._Fld1696RRef IN (SELECT T4._Q_000_F_000RRef AS Q_001_F_000RRef FROM TEMPTABLE T4))) T2 ON (T1._Q_000_F_000RRef = T2.Fld1696RRef)

kirill

А время выполнения -- в секундах тут? Или это вообще какой-то промежуточный запрос был к временной таблицэ?

да секунды

То есть у вас в psql запрос выполняется 60 секунд, а из 1С -- 400. Что происходит? В psql отправляли данные той описи, которые только что закэшыровались?

через 1с нет параллизма

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

kirill

Вт Индексировал по полям поиска/соединения?

kirill

тут в первом запросе не хватает индекса "ИНДЕКСИРОВАТЬ ПО ЭКД" с таким количеством данных

Чисто по ЭКД -- не нужэн ни за чем, оно по другому полю соединяется/ищется. Индэкс (ОПись, ЭКД) топикстартер ужэ создал, и говорит, что вообще не используется.

ну мы гадаем на кофейной гуще так как запросы у него постоянно разные на выходе, надо упрощать все и смотреть план запроса, лучше пусть dump таблиц сделает тогда сможем у себя посмотреть

так был упрощен запрос на чистый селект, сказали 1с не рекомендует так, ок добил, но по плану проблема в другом

Тут ещё такое дело -- если там объём результатов примерно как вы показывали -- то дажэ на самом бытовом SSD из современных эти 15 гигабайт данных должны читаться минуты полторы. А когда не в shared_buffers только три гигабайта -- вообще 20 секунд. Как у вас получается, что оно читает 6 минут и минуту -- тожэ хорошо бы начать выяснять. Ну там, скорость seq scan померить, скорость index-only scan просто на эту таблицу (какую-нибудь произвольную выборку с лимитом 10,000,000 и запретом на seq scan). Что-то тут пока что мне непонятное происходит, и не очень быстрое.

Это, разумеется, не отменяет вопросов -- почему не идёт index-only scan. Я сейчас экспериментирую -- нет, уж 14-то вообще подхватывает примерно в любых ситуацыях.

пока надо с этим разобраться, 300с очень долго

Я вообще не очень понял смысл такого переписывания.

я тоже не понимаю, но готов поэксперементировать для помогающих. Как я только не писал, к итогам обращение происходит долгое

Ну, то есть оно сделает примерно тожэ самое -- только перечисление операцый чуть в менее оптимальном порядке, скорее всего. Ну... Ну, ожыдаемо, что получен примерно тот жэ результат.

Я бы, на вашэм месте, продолжыл разборки с извлечённым запросом (которые вы начали в начале). Там минимум два перспективных направления.

он наверное поэтому и обращается к кластерному индексу, там все поля есть

Для идентичности проверки нужно включить параметры сессии, которые накладывает платформа. SET SESSION default_with_oids = on; SET client_min_messages=error; SET lc_messages to 'en_US.UTF-8'; SET enable_mergejoin = off; SET standard_conforming_strings = off; SET escape_string_warning = off; SET cpu_operator_cost = 0.001; SET lock_timeout = 20000;

Тут реалистично можэт повлиять на план разве только enable_mergejoin -- да и то... Не на это.

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