powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Ошибка при выполнении запроса 1С
25 сообщений из 27, страница 1 из 2
Ошибка при выполнении запроса 1С
    #38820624
argenon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте.

Имеем конфигурацию 1С:Предприятие 8.3 (8.3.5.1248)
Используем для работы PostgreSQL 9.2 (взятую с сайта 1С) на сервере под CentOS 6.6 x86_64.

Выполняется ресурсоемкий запрос

запрос.Текст = "ВЫБРАТЬ
| Организации.Ссылка КАК Организация,
| СУММА(ЕСТЬNULL(ХозрасчетныйОстатки01.СуммаОстаток, 0)) КАК СуммаОстаток01,
| ЕСТЬNULL(ХозрасчетныйОстатки0810.СуммаОстаток, 0) КАК СуммаОстаток0810,
| ЕСТЬNULL(ХозрасчетныйОстатки41.СуммаОстаток, 0) КАК СуммаОстаток41,
| ЕСТЬNULL(ХозрасчетныйОстатки51.СуммаОстаток, 0) КАК СуммаОстаток51,
| ЕСТЬNULL(ХозрасчетныйОстатки51а.СуммаОстаток, 0) КАК СуммаОстаток51а,
| ЕСТЬNULL(ХозрасчетныйОстатки50.СуммаОстаток, 0) КАК СуммаОстаток50,
| ЕСТЬNULL(ХозрасчетныйОстатки51б.СуммаОстаток, 0) КАК СуммаОстаток51б
|ИЗ
| Справочник.Организации КАК Организации
| ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ОсновныеСредства)), , ) КАК ХозрасчетныйОстатки01
| ПО Организации.Ссылка = ХозрасчетныйОстатки01.Организация
| ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(
| КОНЕЦПЕРИОДА(&Дата, ДЕНЬ),
| Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ВложенияВоВнеоборотныеАктивы))
| ИЛИ Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.Материалы)),
| ,
| ) КАК ХозрасчетныйОстатки0810
| ПО Организации.Ссылка = ХозрасчетныйОстатки0810.Организация
| ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.Товары)), , ) КАК ХозрасчетныйОстатки41
| ПО Организации.Ссылка = ХозрасчетныйОстатки41.Организация
| ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.РасчетныеСчета)), , Субконто1.банк.код = ""xxx"") КАК ХозрасчетныйОстатки51
| ПО Организации.Ссылка = ХозрасчетныйОстатки51.Организация
| ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.РасчетныеСчета)), , Субконто1.банк.код = ""xxx"") КАК ХозрасчетныйОстатки51а
| ПО Организации.Ссылка = ХозрасчетныйОстатки51а.Организация
| ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.Касса)), , ) КАК ХозрасчетныйОстатки50
| ПО Организации.Ссылка = ХозрасчетныйОстатки50.Организация
| ПОЛНОЕ СОЕДИНЕНИЕ РегистрБухгалтерии.Хозрасчетный.Остатки(КОНЕЦПЕРИОДА(&Дата, ДЕНЬ), Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.РасчетныеСчета)), , Субконто1.банк.код = ""ххх"") КАК ХозрасчетныйОстатки51б
| ПО Организации.Ссылка = ХозрасчетныйОстатки51б.Организация
|ГДЕ
| Организации.ИНН <> ""ххх""
|
|СГРУППИРОВАТЬ ПО
| Организации.Ссылка,
| ЕСТЬNULL(ХозрасчетныйОстатки0810.СуммаОстаток, 0),
| ЕСТЬNULL(ХозрасчетныйОстатки41.СуммаОстаток, 0),
| ЕСТЬNULL(ХозрасчетныйОстатки51.СуммаОстаток, 0),
| ЕСТЬNULL(ХозрасчетныйОстатки51а.СуммаОстаток, 0),
| ЕСТЬNULL(ХозрасчетныйОстатки50.СуммаОстаток, 0),
| ЕСТЬNULL(ХозрасчетныйОстатки51б.СуммаОстаток, 0)
|
|УПОРЯДОЧИТЬ ПО
| Организации.Наименование";


База данных весит около 1.2 ГБ, во время выполнения запроса в оперативной памяти занимает 10 ГБ. Данные примерно за 2 года.
Понимаю, что запрос не оптимальный, но программисты наотрез отказываются его менять ссылаясь на то, что на MSSQL он работает.

авторВ результате выполнения 1С выдает ошибку

Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
Ошибка СУБД:
ERROR: too many range table entries

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

автор/*
* Check for RT index overflow; it's very unlikely, but if it did happen,
* the executor would get confused by varnos that match the special varno
* values.
*/
if (IS_SPECIAL_VARNO(list_length(glob->finalrtable)))
ereport(ERROR,
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
errmsg("too many range table entries")));

Хотелось бы понять из-за чего возникает такая проблема и как ее можно устранить.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820676
спойлер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
argenon,

перейдите на мсскл
или увольте кодеров

1-е -- проще
2-е -- чревато необходимостью много что переписывать в 1С, за 1С, поперёк 1С

а ошибка -- это 1С
-- "но ведь других нет"(СС)

так что переходите на мсскл и не парьте мозги


спойлер
Код: c
#define IS_SPECIAL_VARNO 	( 	  	varno	) 	   ((varno) >= INNER_VAR)

Код: c
#define INNER_VAR   65000 /* reference to inner subplan */
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820682
argenon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
спойлер,

тут уже дело принципа - понять что происходит.
Поясните, пожалуйста, про INNER_VAR
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820704
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
argenonспойлер,

тут уже дело принципа - понять что происходит.
Поясните, пожалуйста, про INNER_VAR

Для начала посмотрите в какой SQL запрос преобразуется вышеприведенный птичий язык... это раз (перевести с птичьего языка на нормальный SQL не всегда просто)...
два - посмотрите нет ли там партиционирования в тех или иных таблицах учатсвующих в запросе.
По логике эта ошибка может только при партиционировании возникать.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820716
argenon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Boguk,

SQL запрос у меня есть в логе posqtgresql, но не знаю, как бы обезличить данные. Если только очистить таблицы.

Про партиционирование 1с-прораммисты не слышали.

В конфиге postgresql установлено значение
constraint_exclusion = partition
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820750
спойлер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Maxim Bogukargenonспойлер,

тут уже дело принципа - понять что происходит.
Поясните, пожалуйста, про INNER_VAR

Для начала посмотрите в какой SQL запро с преобразуется вышеприведенный птичий язык... это раз (перевести с птичьего языка на нормальный SQL не всегда просто)...
два - посмотрите нет ли там партиционирования в тех или иных таблицах учатсвующих в запросе.
По логике эта ошибка может только при партиционировании возникать.

--Maxim Boguk
<>

поскольку там
Код: sql
1.
	Счет В ИЕРАРХИИ 


то это может быть отнюдь не "один "SQL запрос", а как минимум свёртка с времянками. (1С любит некоторые выборки COPY FROM STDOUT во времяночки, а потом чутка с ними возиться)

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

(эта конструкция и способы её реализации в 1С появились задолго до появлений в субд-ах кляузы "with recursive", и вряд ли её, т.е. коснтрукции, реализацию с тех пор переписывали , тем паче -- субд -зависимым способом )

т.е. в этом случае имеет место быть не простая "трансляция", а трансляция с изподвывертом.


да и тип свёртки -- full join -- не подарок

Опять же , шняги типа
Код: sql
1.
2.
3.
4.
РегистрБухгалтерии.Хозрасчетный.Остатки(
       КОНЕЦПЕРИОДА(&Дата, ДЕНЬ)
       ,Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ОсновныеСредства)), , )
  КАК ХозрасчетныйОстатки01

-- это не таблицы, а некоторые, скорее всего организованные через те же времянки "параметрические" выборки [из таблиц остатков -- сиречь "регистров"]. (могли бы быть хранимками, но это не 1С-вэй).


ps 2тс:
а что пояснять -- есть некая тупая константа -- 65000. вы за неё выкатились. с чем вас и поздравляем.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820842
laskin82
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
argenon, Пожалуйста, "не грузите" местных, а лучше дайте почитать вашим 1С разработчикам

1) http://its.1c.ru/db/metod8dev#content:1556:hdoc

"Использование конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ

В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN (ERROR: "FULL JOIN is only supported with mergejoinable join conditions"). Для реализации полной поддержки FULL OUTER JOIN при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ снижается.

В связи с этим не рекомендуется использовать ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ при работе с PostgreSQL. В большинстве случаев без использования этой конструкции можно обойтись, переписав исходный запрос."
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820843
laskin82
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
argenon, а потом пусть читают до просветления http://kb.1c.ru/articleView.jsp?id=44 (Типичные причины неоптимальной работы запросов и методы оптимизации)
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820853
kihor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
argenon,

На мой взгляд запрос не действительно не оптимальный, т.к. виртуальные таблицы остатков преобразуются в подзапросы, а соединение подзапросов может поставить в тупик оптимизатор (заставит сгенерировать неоптимальный план). Можно запрос переписать с использованием временных таблиц.
Да, и действительно, не рекомендуют использовать FULL OUTER JOIN на Postgres.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820874
argenon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо за советы.
Выложу SQL запрос, который формирует 1с.
Запрос оказался не маленьким поэтому только в виде архива.
https://yadi.sk/d/ujT5Z4brd49yn
Может кому-то будет интересно взглянуть.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820893
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
argenonСпасибо за советы.
Выложу SQL запрос, который формирует 1с.
Запрос оказался не маленьким поэтому только в виде архива.
https://yadi.sk/d/ujT5Z4brd49yn
Может кому-то будет интересно взглянуть.

Запрос на 28MB? Вы смеетесь?
Не удивительно что оно не работает.

--Maxim Boguk
www.postgresql-consulting.ru
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38820901
спойлер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
argenonСпасибо за советы.
Выложу SQL запрос, который формирует 1с.
Запрос оказался не маленьким поэтому только в виде архива.
https://yadi.sk/d/ujT5Z4brd49yn
Может кому-то будет интересно взглянуть.

чотаржу

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


таки они всю иерархию через union ALL-ы и преднаборы {IN (SELECT ..) OR IN(SELECT ...)} -ов от {_ref-ов} собирают ночнче (но не времянки, как я полагал).

Ше ,таки, девр (!) ящетаю. 30 мб sql-я -- это не конь чихнул.

вашим кодерам надо научится "1С-sql" писать правильно, а не в стиле 1С -- "всё в кучку, а потом весь хлам сворачиваем, заметая крошки под ковёр".

Сначала все свертываем по требуемым измерениям ВНУТРИ отдельных таблиц отстатков(добивая 0 отсутствующие в данной табле ), потом результаты или джойним (если не добивали), или (если добивали отсутствующее нолями) -- union-all-аем (как делает унтре сам 1С). и только потом -- крепим "снаружи" (после состоявшейся свёртки) к готовым сверткам справочники -- расшифровки.

тогда 1с-движку не придется так извращаться, перебирая все возможные, но не реализуемые данными варианты "FULL JOIN"-ов

ну вот тут ваши коллеги понабежали, уже с опытом и ссылками -- внемлите, оно полезно, да и на вашем же птичьем жаргоне люди изъясняются -- т.ч. разберётесь.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821030
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
laskin82argenon, Пожалуйста, "не грузите" местных, а лучше дайте почитать вашим 1С разработчикам

1) http://its.1c.ru/db/metod8dev#content:1556:hdoc

"Использование конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ

В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN (ERROR: "FULL JOIN is only supported with mergejoinable join conditions"). Для реализации полной поддержки FULL OUTER JOIN при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ снижается.

В связи с этим не рекомендуется использовать ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ при работе с PostgreSQL. В большинстве случаев без использования этой конструкции можно обойтись, переписав исходный запрос."

Они обкурились? FULL JOIN отлично эмулируется UNION'ом, оверхед на практике в среднем процентов 15.

Интересно, а в своих конфах они ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ используют.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821032
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что касается темы, то уверен, что при трансляции 1с делает много внутренних запросов, а у postgresql predicate pushdown отсутствует как класс. И вряд ли 1совцы писали свой, там для этого тучу чего надо.

Так что либо крестик снимите либо трусы наденьте. То есть либо уходите с PostgreSQL, либо уходите с 1С.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821034
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
argenonСпасибо за советы.
Выложу SQL запрос, который формирует 1с.
Запрос оказался не маленьким поэтому только в виде архива.
https://yadi.sk/d/ujT5Z4brd49yn
Может кому-то будет интересно взглянуть.

Кстати удивительно что оно вообще работает. Потому лично наблюдал как при запросах >5 мб postgresql с очень большой вероятностью падал, причем вместе с операционкой.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821038
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
спойлерСначала все свертываем по требуемым измерениям ВНУТРИ отдельных таблиц отстатков(добивая 0 отсутствующие в данной табле ), потом результаты или джойним (если не добивали), или (если добивали отсутствующее нолями) -- union-all-аем (как делает унтре сам 1С). и только потом -- крепим "снаружи" (после состоявшейся свёртки) к готовым сверткам справочники -- расшифровки.


Замечательный совет. Может им сразу готовый план давать postgre, че уж там? (жалко у него только хинтов нет)

Переходите на MS SQL короче и не дурите людям голову.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821041
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
спойлертаки они всю иерархию через union ALL-ы и преднаборы {IN (SELECT ..) OR IN(SELECT ...)} -ов от {_ref-ов} собирают ночнче (но не времянки, как я полагал).

Это как? Что не догоняю как оператор примитивной рекурсии можно без императивщины (то есть table functions и while'а внутри) реализовать?

А что касается RECURSIVE CTE, то там столько ограничений, что кроме примитивных случаев его особо и не используешь...
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821045
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkielaskin82argenon, Пожалуйста, "не грузите" местных, а лучше дайте почитать вашим 1С разработчикам

1) http://its.1c.ru/db/metod8dev#content:1556:hdoc

"Использование конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ

В СУБД PostgreSQL реализована только частичная поддержка FULL OUTER JOIN (ERROR: "FULL JOIN is only supported with mergejoinable join conditions"). Для реализации полной поддержки FULL OUTER JOIN при работе 1С:Предприятия 8 с PostgreSQL подобный запрос трансформируется в другую форму с эквивалентным результатом, однако эффективность использования конструкции ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ снижается.

В связи с этим не рекомендуется использовать ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ при работе с PostgreSQL. В большинстве случаев без использования этой конструкции можно обойтись, переписав исходный запрос."

Они обкурились? FULL JOIN отлично эмулируется UNION'ом, оверхед на практике в среднем процентов 15.

Интересно, а в своих конфах они ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ используют.

есть одна проблема - 1 full join это 2 Запроса в union
2 full join - 4 запроса в union (если без CTE)
3 full join - 8 запросов и тд
в исходном запросе у нас толи 7 толи 8 FULL JOIN
как я понимаю отсюда и проблемы с длинной запроса.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821053
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim BogukNitro_Junkieпропущено...


Они обкурились? FULL JOIN отлично эмулируется UNION'ом, оверхед на практике в среднем процентов 15.

Интересно, а в своих конфах они ПОЛНОЕ ВНЕШНЕЕ СОЕДИНЕНИЕ используют.

есть одна проблема - 1 full join это 2 Запроса в union
2 full join - 4 запроса в union (если без CTE)
3 full join - 8 запросов и тд
в исходном запросе у нас толи 7 толи 8 FULL JOIN
как я понимаю отсюда и проблемы с длинной запроса.

Это почему 2 FULL JOIN - 4 запроса ?

SELECT COALESCE(A.id, B.id, C.id) A FULL JOIN B ON A.id = B.id FULL JOIN C ON C.id = COALESCE(A.id, B.id) разве не эквивалентно :

(SELECT A.id FROM A) UNION (SELECT B.id FROM B) UNION (SELECT C.id FROM C).

Да если нужно другие поля тянуть, придется в каждом подзапросе LEFT JOIN остальных делать, но запроса то 3.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821196
спойлер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Nitro_Junkieспойлертаки они всю иерархию через union ALL-ы и преднаборы {IN (SELECT ..) OR IN(SELECT ...)} -ов от {_ref-ов} собирают ночнче (но не времянки, как я полагал).

Это как? Что не догоняю как оператор примитивной рекурсии можно без императивщины (то есть table functions и while'а внутри) реализовать?

А что касается RECURSIVE CTE, то там столько ограничений, что кроме примитивных случаев его особо и не используешь...
да примитивно, ДО выполнения запроса они обходят клиентом в цыклах все "иерархии" и составляют наборы условий для каждого уровня. А потом Джойнят Все узлы одной иерархии на все узлы другой -- а результат UNION -ALL -ят.

Т.е. императивно (в DO-while-ах) они пошивают те самые 30 мб сверток перестановками.

если открыть их детище -- мы увидим, что сначала джойнятся выборки с условием

Код: sql
1.
2.
3.
4.
5.
(((T0._AccountRRef IN (
	'\\320\\213D\\011p\\200k\\344Or\\842\\2000\\203\\320\\230\\304'::bytea
	,'\\234\\224P<\\2110\\240uF \\3041S\\032/\\230\\312'::bytea
	,'\\201\\842\\320\\323\\320\\020wgM\\2003\\204\\200\\200\\030]'::bytea
	,'\\200\\200\\004\\304$L\\0414\\001A9(V\\233\\322\\200J'::bytea)))) 


-- это 4 корня какой- то одной иерархии , наверное :
Код: sql
1.
Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ОсновныеСредства)



Потом -- к ним добавляется
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
((((T000._AccountCtRRef IN ('\\200\\200g\\240\\200\\020\\344 D\\204\\203\\234\\320\\341\\320\\004'::bytea
	,'\\231Y\\204/\\301\\013\\300\\300Ja\\244$\\200\\213\\0041\\230'::bytea
	,'\\233\\304h\\0410\\0000\\330\\241YF\\004\\020\\899=\\003\\020\\003'::bytea
	,'\\210G\\0000C1n\\223\\233Lig\\200\\300\\2003Y'::bytea
	,'\\2004>\\220\\2041\\200\\332\\200@(\\004\\0414f\\041\\041\\200'::bytea
	,'\\842\\030\\002\\203\\312\\210\\200\\001D\\0001\\300F#\\041\\011\\320'::bytea
	,'\\202\\211\\000w\\000\\024c&E)D\\034\\0001\\202\\0414b'::bytea
	,'\\240\\032n\\300\\0000\\321\\311_BN\\000\\304 \\223\\221\\241'::bytea
	,'\\201\\210\\030\\310FJt0J\\000\\200\\232?E\\341\\000'::bytea
	,'\\204p\\312\\030\\200=\\240\\200N\\323\\3040A\\200L\\011'::bytea
	,'\\212\\000\\204\\000\\232\\0002\\310KBhtRmb\\800\\330'::bytea)))
OR ((T000._AccountCtRRef IN ('\\200\\240![\\342g\\334\\204M\\331\\243\\041M\\011\\0410S'::bytea
	,'\\200\\321\\010A\\0113[\\030Eg\\210\\230J\\300\\302\\000'::bytea
	,'\\234\\230=:\\200\\231\\2428E\\201\\202\\010<.|\\340'::bytea
	,'\\000\\210\\341;u\\014\\302\\800O4"\\3102]<\\0000'::bytea
	,'\\242J\\0411f\\013\\201\\842\\030I\\211\\240w\\201nF\\2000'::bytea
	,'\\210\\301\\300\\021\\000\\033\\310\\003@\\304\\0002B\\340\\020m\\230'::bytea
	,'\\202L?\\022\\012&\\020B@_\\203\\200W\\304\\200\\203'::bytea
	,'\\201ZW\\203\\200`eKA(\\020\\030\\322\\0410\\233\\000'::bytea
	,'\\242l$\\200_j]\\842G0\\204~\\020^kF'::bytea
	,'\\201i\\0413\\020\\010\\304S\\014J@\\0414o\\011\\202w\\202'::bytea
	,'\\234&\\300i\\341\\024\\332\\201E\\200\\202tOA\\320\\340'::bytea
	,'\\210Y3C\\202\\324s\\203Do\\0002\\013\\343:\\340\\302'::bytea
	,'\\202m\\2019\\213A\\0000\\230B\\201\\340\\304\\312\\210\\300\\203'::bytea
	,'\\320\\200Od''\\320\\220\\233B1\\200/ \\2000\\232\\310'::bytea))))) 


-- это скорее всего получено из
Код: sql
1.
2.
Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ВложенияВоВнеоборотныеАктивы))
| ИЛИ Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.Материалы)



-- вопрос, где они набрали то дикое количество перестановок (комбинаторику) мне пока не ясен
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821214
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
спойлерNitro_Junkieпропущено...


Это как? Что не догоняю как оператор примитивной рекурсии можно без императивщины (то есть table functions и while'а внутри) реализовать?

А что касается RECURSIVE CTE, то там столько ограничений, что кроме примитивных случаев его особо и не используешь...
да примитивно, ДО выполнения запроса они обходят клиентом в цыклах все "иерархии" и составляют наборы условий для каждого уровня. А потом Джойнят Все узлы одной иерархии на все узлы другой -- а результат UNION -ALL -ят.

Т.е. императивно (в DO-while-ах) они пошивают те самые 30 мб сверток перестановками.

если открыть их детище -- мы увидим, что сначала джойнятся выборки с условием

Код: sql
1.
2.
3.
4.
5.
(((T0._AccountRRef IN (
	'\\320\\213D\\011p\\200k\\344Or\\842\\2000\\203\\320\\230\\304'::bytea
	,'\\234\\224P<\\2110\\240uF \\3041S\\032/\\230\\312'::bytea
	,'\\201\\842\\320\\323\\320\\020wgM\\2003\\204\\200\\200\\030]'::bytea
	,'\\200\\200\\004\\304$L\\0414\\001A9(V\\233\\322\\200J'::bytea)))) 


-- это 4 корня какой- то одной иерархии , наверное :
Код: sql
1.
Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ОсновныеСредства)



Потом -- к ним добавляется
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
((((T000._AccountCtRRef IN ('\\200\\200g\\240\\200\\020\\344 D\\204\\203\\234\\320\\341\\320\\004'::bytea
	,'\\231Y\\204/\\301\\013\\300\\300Ja\\244$\\200\\213\\0041\\230'::bytea
	,'\\233\\304h\\0410\\0000\\330\\241YF\\004\\020\\899=\\003\\020\\003'::bytea
	,'\\210G\\0000C1n\\223\\233Lig\\200\\300\\2003Y'::bytea
	,'\\2004>\\220\\2041\\200\\332\\200@(\\004\\0414f\\041\\041\\200'::bytea
	,'\\842\\030\\002\\203\\312\\210\\200\\001D\\0001\\300F#\\041\\011\\320'::bytea
	,'\\202\\211\\000w\\000\\024c&E)D\\034\\0001\\202\\0414b'::bytea
	,'\\240\\032n\\300\\0000\\321\\311_BN\\000\\304 \\223\\221\\241'::bytea
	,'\\201\\210\\030\\310FJt0J\\000\\200\\232?E\\341\\000'::bytea
	,'\\204p\\312\\030\\200=\\240\\200N\\323\\3040A\\200L\\011'::bytea
	,'\\212\\000\\204\\000\\232\\0002\\310KBhtRmb\\800\\330'::bytea)))
OR ((T000._AccountCtRRef IN ('\\200\\240![\\342g\\334\\204M\\331\\243\\041M\\011\\0410S'::bytea
	,'\\200\\321\\010A\\0113[\\030Eg\\210\\230J\\300\\302\\000'::bytea
	,'\\234\\230=:\\200\\231\\2428E\\201\\202\\010<.|\\340'::bytea
	,'\\000\\210\\341;u\\014\\302\\800O4"\\3102]<\\0000'::bytea
	,'\\242J\\0411f\\013\\201\\842\\030I\\211\\240w\\201nF\\2000'::bytea
	,'\\210\\301\\300\\021\\000\\033\\310\\003@\\304\\0002B\\340\\020m\\230'::bytea
	,'\\202L?\\022\\012&\\020B@_\\203\\200W\\304\\200\\203'::bytea
	,'\\201ZW\\203\\200`eKA(\\020\\030\\322\\0410\\233\\000'::bytea
	,'\\242l$\\200_j]\\842G0\\204~\\020^kF'::bytea
	,'\\201i\\0413\\020\\010\\304S\\014J@\\0414o\\011\\202w\\202'::bytea
	,'\\234&\\300i\\341\\024\\332\\201E\\200\\202tOA\\320\\340'::bytea
	,'\\210Y3C\\202\\324s\\203Do\\0002\\013\\343:\\340\\302'::bytea
	,'\\202m\\2019\\213A\\0000\\230B\\201\\340\\304\\312\\210\\300\\203'::bytea
	,'\\320\\200Od''\\320\\220\\233B1\\200/ \\2000\\232\\310'::bytea))))) 


-- это скорее всего получено из
Код: sql
1.
2.
Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ВложенияВоВнеоборотныеАктивы))
| ИЛИ Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.Материалы)



-- вопрос, где они набрали то дикое количество перестановок (комбинаторику) мне пока не ясен

Жесть... А я еще считал, что реализация примитивной рекурсии через "системную" табличную функцию, DO WHILE, запросы как строки в качестве параметров и EXEC внутри (у PostgreSQL) или через генерацию аналогичной табличной функции для каждого набора запросов и именем из md5 hash'а (у MS SQL) - перебор. Но читать на клиенте иерархию и embedd'ить ее в запрос это конечно адский ад.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821446
laskin82
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
спойлерчотаржу...
доставляет....
Ше ,таки, девр (!) ящетаю. 30 мб sql-я -- это не конь чихнул.


Хотел промолчать, но после перехода на критику 1С не могу :) Степень уровня кода запроса 1С из первого поста топика превышает все допустимые пределы. Поехали разбирать по косточкам:

1) Прямая рекомендация не использовать ПОЛНОЕ СОЕДИНЕНИЕ

2) ЗНАЧЕНИЕ(ПланСчетов.хозрасчетный.ОсновныеСредства) рекомендация не использовать значения в запросе, а передавать параметром в запрос.

3) Субконто1.банк.код = ""xxx"" эпичность этого выражения просто зашкаливает. тк
а) Субконто1 - составной тип данных и фильтрация по нему сгенерирует соединение еще с каждой таблицой данных
б) .банк. - получение данных через точку от полей составного типа

решение, пример: В данном запросе используется обращение к реквизитам регистратора. Регистратор является полем составного типа, которое может принимать значения ссылки на один из 56 видов документов.

Запрос.Текст = "ВЫБРАТЬ
| Продажи.Регистратор.Номер,
| Продажи.Регистратор.Дата,
| Продажи.Контрагент,
| Продажи.Количество,
| Продажи.Стоимость
|ИЗ
| РегистрНакопления.Продажи КАК Продажи
|ГДЕ ...

SQL-текст этого запроса будет включать 56 левых соединений с таблицами документов. Это может привести к серьезным проблемам производительности при выполнении запроса. Однако, для решения данной конкретной задачи нет необходимости соединяться со всеми 56 видами документов. Условия запроса таковы, что при его выполнении будут выбраны только движения документов "РеализацияТоваровУслуг" и "ЗаказыПокупателя". В этом случае мы можем значительно ускорить работу запроса, ограничив количество соединений при помощи функции ВЫРАЗИТЬ().

Другими словами никакой транслятор запросов и оптимизатор не способен привести в божеский вид изначально кривой код запроса.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821469
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
laskin82,

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

Другими словами никакой транслятор запросов и оптимизатор не способен привести в божеский вид изначально кривой код запроса.

Не поверите, но оптимизаторы запросов самих СУБД именно этим и занимаются. Пытаются понять как то что написал разработчик максимально быстрее выполнить. И у нормальных СУБД там такое количество ухищрений, чтобы можно было просто "сесть и поехать", что видно что они стараются (хотя тоже есть куда расти). Но у 1цэ конечно свой путь, просто не рекомендовать все что можно.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821483
laskin82
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Nitro_Junkielaskin82,

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


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

авторНо у 1цэ конечно свой путь
Вы бывший/действующий сотрудник компании 1С? Если нет, то не говорите того, чего не знаете.
...
Рейтинг: 0 / 0
Ошибка при выполнении запроса 1С
    #38821495
спойлер
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
laskin82,

то-то и оно, что прослойка между кодером и СУБД (под наименованием "плятформа.1с" )привносит сложности (в сложных случаях) , а не упрощает.

после дцати лет развития 1С их язык запросов (убожество времён 7) пришел практически к стандартному SQL (за отсутствием некоторых крайне полезных вещей , типа exists(), которых этим недоумкам пока не удалось/захотелось реализовывать)

далее:
трансляция с этого "почти sql" к реальному SQL производит такие плюхи (см), что по итогу якобы недоумок--1с--кодер должен не просто хорошо понимать SQL, но и детально представлять внутреннюю кухню "транслятора" (недотрахслятора, если быть точнее)

и т.д.

т.е. по итогу имеем не упрощение пользования системой за счет прослойки, а напротив -- усложнение.
//это относится ко многим подобным прослойкам, а не токмо 1С//

но в простых случаях накидать запрос в конструкторе зато может и полный недоумок, не знающий не только SQL но и 1с-8-диалекта SQL.

//вот за визуальный конструктор запросов , правда до слияния с гробом ээээ, не помню уж его имени, -- их можно было хвалить. хотя и там были недочёты и неловкости//

PPS а если ещё и скрестить с вечным секстанством и прочей маркеторийей -- то отстреливать конфигурастов и их пророков как бешеных собак -- единственное верное отношение.
...
Рейтинг: 0 / 0
25 сообщений из 27, страница 1 из 2
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Ошибка при выполнении запроса 1С
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]