Крючков Владимир

4858
Рейтинг

ivanov660
Владимир Крючков



  •   Регистрация: 02.02.2011 (14 лет назад)

  •   Был(а) на сайте: вчера в 21:20

Друзья
  • Alexander Kondrin
  • Антон Коваленко
  • Артур Аюханов
  • Группа Полипластик
  • Александр Алехин
  • Александр Егоров
  • Дмитрий Виссаров
  • Карина Арсенян
  • Евгений Комиссаров
  • Ольга Терскова
  • Димтрий Павлюченко
  • Дмитрий Котов
  • Виктор Клевцов
  • Константин Скворцов
  • Игорь Антонов
  • Дмитрий Малышев
Подписчики 385
Группы

Профессиональный разработчик

IE 2017 Докладчик

IE 2018 Докладчик

IE 2019 Докладчик

Докладчик Meetup

IE 2021 Докладчик

Лауреат Infostart Awards

IE2021_msk Online

IE2022 Докладчик

IE2023 Докладчик

TEAMLEAD EVENT 2025 Докладчик

Рейтинг 4858

Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres
+44 –

Статья Программист 1C:ERP Бесплатно (free) Нет файла HighLoad оптимизация

Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.

10.11.2025    3165    ivanov660    36       

44
Используем частотный анализ количества выполненных запросов для выявления проблем оптимизации
+22 –

Статья Для всех Универсальные Бесплатно (free) Нет файла HighLoad оптимизация

Влияние сортировки на быстродействие динамических списков.

27.10.2025    2409    ivanov660    8       

22
Проблемы производительности. Особенности подсчета количества строк в таблице данных СУБД Postgres
+19 –

Статья Программист Универсальные Бесплатно (free) Нет файла HighLoad оптимизация

Расскажем, как выполняется подсчет количества записей и что можно улучшить.

20.10.2025    1388    ivanov660    7       

19
Проблемы производительности. Оператор различные в динамических списках
+61 –

Статья Программист 1С v8.3 1C:ERP Бесплатно (free) Нет файла HighLoad оптимизация

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

18.02.2025    7516    ivanov660    39       

61
Проблемы производительности. Индексация с дополнительным упорядочиванием
+55 –

Статья Системный администратор Программист 1C:ERP Бесплатно (free) Нет файла HighLoad оптимизация

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

04.02.2025    6073    ivanov660    21       

55
Поиск дублей по полям ключей шапки, табличных частей (используем hash функцию)
+22 –

Статья Программист 1С v8.3 Запросы Универсальные Бесплатно (free) Нет файла Математика и алгоритмы Запросы

Рассмотрим быстрый алгоритм поиска дублей с использованием hash функции по набору полей шапки и табличных частей.

08.07.2024    4241    ivanov660    9       

22
Поиск и анализ длительных вызовов - CALL, SCALL
+62 –

Статья Системный администратор Программист Универсальные Бесплатно (free) Нет файла HighLoad оптимизация Технологический журнал

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    9957    ivanov660    13       

62
Простой менеджер данных (simple data manager)
+84 –

Инструменты и обработки Программист 1С v8.3 1C:Бухгалтерия Абонемент ($m) Внешняя обработка (ert,epf) Перенос данных 1C

Когда требуется быстро и удобно перенести данные между одинаковыми, различными конфигурациями.

3 стартмани

13.06.2024    8117    94    ivanov660    32       

84
Опыт оптимизации 1С на PostgreSQL
+84 –

Статья Системный администратор Программист Универсальные Бесплатно (free) Нет файла HighLoad оптимизация

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    20232    ivanov660    7       

84
Мигрируем с MS SQL на PostgreSQL
+80 –

Статья Системный администратор Универсальные Бесплатно (free) Нет файла Администрирование СУБД

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

13.11.2023    26038    ivanov660    36       

80
Смотреть все

Комментарии

HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #36 13.11.25 0:13
(35)
К одной из причин можно отнести следующее утверждение:

Планировщик postgres достаточно плохо работает с составными типами. Довольно сильно влияет на формирование плана статистика. И как вы знаете, то в postgres статистика по умолчанию строится одноколоночная (в ms sql тут дела значительно лучше). А для формирования лучшего плана планировщик должен учитывать две колонки вместе, а не по отдельности.
Поэтому одним из вариантов решения могло бы быть создания многоколоночной статистики по двум полям RecorderTRef и RecorderRRef. На практике данное решение снижает количество плохих планов, но проблемно работает для очень больших таблиц.
HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #30 11.11.25 15:35
(29) "Следите за руками" - я бы сказал так: рекомендации 1С они "немного" размытые и там буквально говориться делайте правильно - будет все хорошо.
Касательно добавляйте условия внутрь виртуальной таблицы - это правильно, т.к. если мы срежем фильтром количество записей внутри вложенного запроса, то это будет лучше чем выбрать все записи из вложенного запроса, а потом обрезать их. Особенно если есть соединения с виртуальной таблицей.
HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #26 11.11.25 11:28
(21) Предложите лучший вариант для названия одноразовой временной переменной (стр_н - кратко "строка новая"). Запишу в копилку.
HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #25 11.11.25 11:22
(23) Снимаю шляпу) Мне потребовалось не менее нескольких часов чтобы разобраться в проблеме.
HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #24 11.11.25 11:19
(22) "Запасы И Потребности" регистр накопления с видом остатки, поэтому виртуальная таблица Обороты() не имеет таблицы итогов для оборотов. Следовательно будет создан вложенный запрос (для формирования виртуальной таблицы Обороты), который будет использовать физическую таблицу движений. Отсюда следует, что такой подход эффективнее не будет. Как-то так)
HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #20 11.11.25 9:50
(17) Преобразование конструкции В () 1С запроса в SQL формат от этого с большой вероятностью не поменяется. К тому же учитывая что это виртуальная таблица, то сам запрос будет сложнее и соответственно план запроса. Поэтому вероятность формирования "плохого" плана увеличится.
HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #8 10.11.25 13:20
(5)Да, скорее всего отработает также, только запись будет более громоздкая.
Только обратите внимание, что в запросе стоят РАЗЛИЧНЫЕ. Если же не будет этого ключевого слова и будьте осторожнее, иначе можете словить дубли строк.
HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #4 10.11.25 11:04
(2) Так судя по всему работает планировщик. В данном примере планировщик формировал "плохой" план, в других случаях план был лучше.
HighLoad › Проблемы производительности: Оптимизация запросов с оператором «В» для составных типов в 1С и СУБД Postgres › #3 10.11.25 11:01
(1) Такую метрику не замеряли, могу сказать что общее количество одномоментно запрашивающих что-то пользователей из базы в среднем в интервалы максимальной нагрузки в районе 100 пользователей.
HighLoad › Используем частотный анализ количества выполненных запросов для выявления проблем оптимизации › #7 28.10.25 17:11
(6)
Цитата
Имелось в виду, что убили старый индекс, вместо него создан новый индекс, те запросы использующие старый индекс (если они конечно есть) всплывут в топ проблемных.
Мы только добавили новый индекс. Где написано что мы удаляли старый?
Скажу так в некоторых случаях действительно приходится удалять старые индексы, но это сильно зависит от ситуации.

Цитата
Хех, видимо потому, что при поиске сканируется не таблица, а индекс (Индекс_5) в котором нет ДатыДокумента.
Видимо я не понял мысль, но все же предположу что вы заблуждаетесь. И в статье я написал почему работает сканирование и нужна сортировка в первом случае, а почему во втором оптимальнее.