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

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

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

3 стартмани

13.06.2024    8117    94    ivanov660    32       

84

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

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

20.11.2023    20232    ivanov660    7       

84

Статья Системный администратор Универсальные Бесплатно (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) в котором нет ДатыДокумента.
Видимо я не понял мысль, но все же предположу что вы заблуждаетесь. И в статье я написал почему работает сканирование и нужна сортировка в первом случае, а почему во втором оптимальнее.