Во всех типовых конфигурациях есть мониторинг через APDEX, там можно понять, как изменение параллелизма повлияло на производительность ключевых операций бизнеса. Анализ проблем производительности, на мой взгляд, правильно начинать со стороны именно 1С, а не СУБД.
Еще бы хотел добавить по вашему абзацу по MSSQL. Кажется, что рекомендация от 1С отключать его давно устарела. Мы всегда его включали и получали значительный эффект. Это как раз один из тех случаев, когда после миграции на PostgreSQL начинает работать медленнее, потому что там не развит так параллелизм. Главное правильно настроить, поставить верный cost threshold for parallelism (кажется мы ставили значение в районе 300), чтобы он не пытался использовать параллелизм там, где от него больше вреда, чем пользы.
Допустим у нас есть большая временная таблица, которая не помещается в temp_buffers, и которая по этой причине сбрасывается на диск при наполнении данными (INSERT INTO pg_temp.tt). При использовании параллелизма она сразу будет читаться с диска или будет выполнено повторное ее сбрасывание на диск?
Мы в Tantor Postgres с подобной проблемой сталкивались. Подробнее о решении здесь и здесь. Есть еще одна проблема долгого планирования, которая связана не со статистикой, а с перебором варианта соединения таблиц. Текст запроса - https://disk.360.yandex.ru/d/q57qF5eoy6KQNg, план выполнения - https://explain.tensor.ru/archive/explain/4a10aec20a04cd5cfa312221e61a47f1:0:2025-08-06#explain Planning time при разных значениях join_collapse_limit и from_collapse_limit: 12 - 591 ms 10 - 155 ms 8 - 58 ms Возможно здесь могло помочь кеширование плана запроса или оптимизация перебора вариантов соединения таблиц? Это не единственный такой пример, уже много таких случаев встречал
Ну так вам пришлось залезать в ядро, да ещё и в парсер. Оно всегда сложнее в тестировании и поддержке. К тому же SQL Server чтобы переварить такие объемы статистики благоразумно делает это фоном, в отдельном процессе. Реализуя как extension вы могли бы вынести это в bgworker.
Не понимаю, почему ты считаешь, что MSSQL делает расчет статистики фоном в отдельном процессе. Там также как и в постгрес регламентно считают всю статистику в базе. Пример насколько это может быть тяжелый процесс рассмотрен в статье https://infostart.ru/1c/articles/2184112/. По опыту эксплуатации MSSQL у нас тоже был подобный кейс и мы даже думали прийти к тому, что статистика будет считаться чуть ли не круглосуточно (закончился один расчет - запустился новый, т.к. за время прошлого расчета она уже устарела). Асинхронный расчет статистики в MS SQL есть, но его часто отключают, иначе можно поймать ожидания на блокировке схемы.
Собирая такую уточненную статистику отдельно, можно быть уверенным, что не создашь performance cliff на ровном месте, если такая таблица с STAT_MULTIPLIER=1000 случайно попадет у пользователя в список ANALYZE.
Если DBA запускает ANALYZE, то как и в случае с MSSQL он должен быть готов к тому, что статистика может считаться долго, если выборка будет большой. Преимуществом MSSQL здесь является то, что он может считать статистику по одной таблице многопоточно.
Вот тут совсем не понял. Можно делать как все - собирать стату на полное сканирование (если дошло до конца). Отличается на видимость снапшота от реального состояния, но вроде бы статистика у нас и так всегда не свежая, тут проблем быть не должно. Зато получаем статистику почти бесплатно - ведь всего затрат - хранить "резервуар" фиксированного размера, а для ndistinct'a в PG уже давно HyperLogLog есть ...
А если есть фильтры, так это здорово - есть альтернативная статистика для конкретных фильтров. SQL Server хранит ее отдельно и очень по-месту использует. Хотя в нашем случае, это уже может быть и перебор.
Предложение понятно, идея хорошая, передал информацию коллегам из команды разработки. Но для реализации задачи нужны кейсы, где мы поймем, что это даст нам профит. Как, например, в случае с STATMULTIPLIER, он работает и помогает на конкретных кейсах.
Можешь пояснить, чем наша реализация сложнее твоего предложения? Предложенный тобой подход сбора статистики во время выполнения SeqScan'a или даже IndexScan'a может дать смещённую выборку (query patterns != data distribution), а нам было важно сделать это прозрачным для приложения и с предсказуемым поведением (время ANALYZE vs точность). К тому же в MSSQL реализован подобный подход управления размером выборки для расчета статистики - UPDATE STATISTICS table_name SAMPLE N PERCENT
Интересный вопрос! На самом деле, подход с расширением списков most_common_vals не всегда является оптимальным решением.
Показательный пример — Microsoft SQL Server. В MSSQL статистика хранит фиксированное количество значений:
До 200 шагов в гистограмме (histogram steps)
Без возможности расширения этого лимита
При этом MSSQL успешно работает с огромными таблицами и сложными распределениями данных. Как? За счет более умных алгоритмов выборки при сборе статистики и адаптивных стратегий построения гистограмм, которые фокусируются на наиболее значимых диапазонах данных.
В PostgreSQL максимальный default_statistics_target = 10000, что позволяет хранить до 10000 значений в most_common_vals. Но проблема не в количестве хранимых значений, а в качестве выборки, по которой эти значения рассчитываются. Поэтому мы и добавили STATMULTIPLIER в Tantor Postgres
Спасибо за вопрос! Да, ALTER TABLE... ALTER COLUMN SET STATISTICS действительно позволяет гранулярно управлять статистикой на уровне отдельных колонок. Однако это решает другую проблему.
SET STATISTICS меняет количество хранимых статистик (размер массивов most_common_vals, most_common_freqs, histogram_bounds в pg_stats), но не влияет на размер анализируемой выборки при расчете этих статистик. Выборка по-прежнему остается ограниченной формулой 300 × statistics_target.
Альтернативный вариант — вручную установить n_distinct через ALTER TABLE... ALTER COLUMN SET (n_distinct = ...), но это статическое значение, которое:
Требует ручного пересчета при изменении распределения данных
Не адаптируется автоматически при росте таблицы
Не учитывает эволюцию данных со временем
В реальных production-системах распределение данных постоянно меняется, и автоматический расчет с расширенной выборкой (STATMULTIPLIER) оказывается более практичным и надежным решением, чем ручное управление параметрами.
Расширенная статистика (CREATE STATISTICS) в данном случае не поможет, так как она предназначена для учета корреляций между колонками, а наша проблема была в недооценке n_distinct для отдельной колонки _recorderrref.
В PostgreSQL для расчета скалярных статистик (n_distinct, most_common_vals) используется параметр default_statistics_target, который ограничивает размер выборки формулой: 300 × default_statistics_target. Увеличив допустим default_statistics_target до 1000 мы увеличим количество хранимых статистик и соответственно время планирования запросов, при этом проблему можем не решить, и придется увеличивать еще.
STATMULTIPLIER в Tantor Postgres решает эту проблему, позволяя увеличить объем анализируемой выборки для конкретной колонки без увеличения количества хранимых статистик. Формула становится: 300 × default_statistics_target × STATMULTIPLIER. Это похоже на SAMPLE N PERCENT в MSSQL, но с более гранулярным контролем на уровне отдельных колонок.
Кстати, в Tantor Postgres также есть multicolumn-статистика по полям составных индексов, но это отдельная возможность, не связанная с данным кейсом.
Когда я работал в Магните, то мы на основе БСП сделали свою подсистему, которая позволяла управлять индексами в пользовательском режиме. Было даже автоматическое создание в процедурах обработчиков обновления, если индекс был удален в результате реструктуризации таблицы...
Кмк, это слабоприменимо. В норме там должно быть попадание в индексы, а в них порядком полей не получится жонглировать.
Для 1С характерно соединение таблиц по большому количеству полей, поэтому при таких соединениях не всегда можно найти покрывающий условия такого соединения индекс. Вот тут оптимизация и будет полезна. Что касается настроек индексов, то в платформе 1С 8.3.26 завезли наконец-то возможность создавать кастомные индексы, что конечно хорошо.
А на сколько claude помогает/ускоряет написание таких фич как sort pushdown?
Российские IT-компании массово «нанимают» нейросотрудников
HR диасофт: знакомьтесь, Александр Сахаров
Вторая и третья оптимизации для 1С не актуальны, т.к. там таких кейсов почти нет)
Во всех типовых конфигурациях есть мониторинг через APDEX, там можно понять, как изменение параллелизма повлияло на производительность ключевых операций бизнеса.
Анализ проблем производительности, на мой взгляд, правильно начинать со стороны именно 1С, а не СУБД.
Еще бы хотел добавить по вашему абзацу по MSSQL. Кажется, что рекомендация от 1С отключать его давно устарела.
Мы всегда его включали и получали значительный эффект. Это как раз один из тех случаев, когда после миграции на PostgreSQL начинает работать медленнее, потому что там не развит так параллелизм. Главное правильно настроить, поставить верный cost threshold for parallelism (кажется мы ставили значение в районе 300), чтобы он не пытался использовать параллелизм там, где от него больше вреда, чем пользы.
А про то, что в постгресе параллелизм не будет работать, если в запросе есть что-то связанное с временной таблицей, не написали
Допустим у нас есть большая временная таблица, которая не помещается в temp_buffers, и которая по этой причине сбрасывается на диск при наполнении данными (INSERT INTO pg_temp.tt). При использовании параллелизма она сразу будет читаться с диска или будет выполнено повторное ее сбрасывание на диск?
Мы в Tantor Postgres его уже давно портировали. Задача возникла как раз также из кейса 1С. У меня даже проблемный план сохранился, вот он - https://explain.tensor.ru/archive/explain/81c9c7b81127e66de65c8ebe146e15f4:0:2025-05-30
Мы в Tantor Postgres с подобной проблемой сталкивались.
Подробнее о решении здесь и здесь.
Есть еще одна проблема долгого планирования, которая связана не со статистикой, а с перебором варианта соединения таблиц. Текст запроса - https://disk.360.yandex.ru/d/q57qF5eoy6KQNg, план выполнения - https://explain.tensor.ru/archive/explain/4a10aec20a04cd5cfa312221e61a47f1:0:2025-08-06#explain
Planning time при разных значениях join_collapse_limit и from_collapse_limit:
12 - 591 ms
10 - 155 ms
8 - 58 ms
Возможно здесь могло помочь кеширование плана запроса или оптимизация перебора вариантов соединения таблиц? Это не единственный такой пример, уже много таких случаев встречал
Спасибо! При реализации следующих задач, связанных со статистикой, это обязательно учтем!
Не понимаю, почему ты считаешь, что MSSQL делает расчет статистики фоном в отдельном процессе. Там также как и в постгрес регламентно считают всю статистику в базе. Пример насколько это может быть тяжелый процесс рассмотрен в статье https://infostart.ru/1c/articles/2184112/. По опыту эксплуатации MSSQL у нас тоже был подобный кейс и мы даже думали прийти к тому, что статистика будет считаться чуть ли не круглосуточно (закончился один расчет - запустился новый, т.к. за время прошлого расчета она уже устарела).
Асинхронный расчет статистики в MS SQL есть, но его часто отключают, иначе можно поймать ожидания на блокировке схемы.
Если DBA запускает ANALYZE, то как и в случае с MSSQL он должен быть готов к тому, что статистика может считаться долго, если выборка будет большой. Преимуществом MSSQL здесь является то, что он может считать статистику по одной таблице многопоточно.
Предложение понятно, идея хорошая, передал информацию коллегам из команды разработки. Но для реализации задачи нужны кейсы, где мы поймем, что это даст нам профит. Как, например, в случае с STATMULTIPLIER, он работает и помогает на конкретных кейсах.
Можешь пояснить, чем наша реализация сложнее твоего предложения?
Предложенный тобой подход сбора статистики во время выполнения SeqScan'a или даже IndexScan'a может дать смещённую выборку (query patterns != data distribution), а нам было важно сделать это прозрачным для приложения и с предсказуемым поведением (время ANALYZE vs точность).
К тому же в MSSQL реализован подобный подход управления размером выборки для расчета статистики - UPDATE STATISTICS table_name SAMPLE N PERCENT
Интересный вопрос! На самом деле, подход с расширением списков most_common_vals не всегда является оптимальным решением.
Показательный пример — Microsoft SQL Server. В MSSQL статистика хранит фиксированное количество значений:
До 200 шагов в гистограмме (histogram steps)
Без возможности расширения этого лимита
При этом MSSQL успешно работает с огромными таблицами и сложными распределениями данных. Как? За счет более умных алгоритмов выборки при сборе статистики и адаптивных стратегий построения гистограмм, которые фокусируются на наиболее значимых диапазонах данных.
В PostgreSQL максимальный default_statistics_target = 10000, что позволяет хранить до 10000 значений в most_common_vals. Но проблема не в количестве хранимых значений, а в качестве выборки, по которой эти значения рассчитываются. Поэтому мы и добавили STATMULTIPLIER в Tantor Postgres
Спасибо за вопрос! Да,
ALTER TABLE... ALTER COLUMN SET STATISTICSдействительно позволяет гранулярно управлять статистикой на уровне отдельных колонок. Однако это решает другую проблему.SET STATISTICS меняет количество хранимых статистик (размер массивов most_common_vals, most_common_freqs, histogram_bounds в pg_stats), но не влияет на размер анализируемой выборки при расчете этих статистик. Выборка по-прежнему остается ограниченной формулой
300 × statistics_target.Альтернативный вариант — вручную установить n_distinct через
ALTER TABLE... ALTER COLUMN SET (n_distinct = ...), но это статическое значение, которое:Требует ручного пересчета при изменении распределения данных
Не адаптируется автоматически при росте таблицы
Не учитывает эволюцию данных со временем
В реальных production-системах распределение данных постоянно меняется, и автоматический расчет с расширенной выборкой (STATMULTIPLIER) оказывается более практичным и надежным решением, чем ручное управление параметрами.
Расширенная статистика (CREATE STATISTICS) в данном случае не поможет, так как она предназначена для учета корреляций между колонками, а наша проблема была в недооценке n_distinct для отдельной колонки
_recorderrref.В PostgreSQL для расчета скалярных статистик (n_distinct, most_common_vals) используется параметр default_statistics_target, который ограничивает размер выборки формулой: 300 × default_statistics_target. Увеличив допустим default_statistics_target до 1000 мы увеличим количество хранимых статистик и соответственно время планирования запросов, при этом проблему можем не решить, и придется увеличивать еще.
STATMULTIPLIER в Tantor Postgres решает эту проблему, позволяя увеличить объем анализируемой выборки для конкретной колонки без увеличения количества хранимых статистик. Формула становится: 300 × default_statistics_target × STATMULTIPLIER. Это похоже на SAMPLE N PERCENT в MSSQL, но с более гранулярным контролем на уровне отдельных колонок.
Кстати, в Tantor Postgres также есть multicolumn-статистика по полям составных индексов, но это отдельная возможность, не связанная с данным кейсом.
Технические подробности раскрыли в статье https://infostart.ru/1c/articles/2535895/
Добрый день.
Количество сотрудников на сложность создания правил не влияет. Что у вас за конфигурация 1с? ERP?
Мы делимся с сообществом некоторыми наработками, исправлениями багов, но провести в релиз ванильного postgres сложные оптимизации, доработки непросто.
Когда я работал в Магните, то мы на основе БСП сделали свою подсистему, которая позволяла управлять индексами в пользовательском режиме. Было даже автоматическое создание в процедурах обработчиков обновления, если индекс был удален в результате реструктуризации таблицы...
Для 1С характерно соединение таблиц по большому количеству полей, поэтому при таких соединениях не всегда можно найти покрывающий условия такого соединения индекс. Вот тут оптимизация и будет полезна.
Что касается настроек индексов, то в платформе 1С 8.3.26 завезли наконец-то возможность создавать кастомные индексы, что конечно хорошо.