Вы упомянули в статье, что при высоких значений collapse_limit приходит OOM Killer из-за повышенной утилизации ОЗУ при планировании запроса. Может быть geqo был отключен? Про 1С могу сказать так, что между ситуациями "все тормозит" и "работает быстро" или "приходит OOM Killer" и "теперь все ок" как раз и стоит разница в значениях по параметрам collapse_limit
Да причем тут рекомендации от фирмы 1С. Вы сами для прохождения теста 30К поставили *_collapse_limit = 20 и пишите об этом в статье. Зачем? Чем 8 не устроило?
Это нормальный вид. Установите данный параметр перед выполнением запроса (как делает платформа 1С) и тогда должны получить результат: SET standard_conforming_strings=off;
Только как вы боритесь с тем что auto_dump так же как auto_explain искажают запросы с отборами
Не совсем понял, что вы имеете ввиду под искажением? Стоит учитывать, что платформа 1С при каждом выполнении запроса устанавливает вот эти параметры, это может влиять на выбор плана запроса: SET enable_mergejoin=off; SET escape_string_warning=off; SET standard_conforming_strings=off; SET cpu_operator_cost=0.001;
Если вы выполняете запрос без установки этих параметров в pgadmin, то результат может быть другой
Во всех типовых конфигурациях есть мониторинг через 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 Возможно здесь могло помочь кеширование плана запроса или оптимизация перебора вариантов соединения таблиц? Это не единственный такой пример, уже много таких случаев встречал
Буквально свежий пример от одного из клиентов.
Периодически кончается оперативная память на сервере субд и он уходит в рестарт. В настройках видим коллапс_лимиты в значении 8.
Подписка Claude Pro на месяц 2100
Моя версия https://habr.com/ru/companies/tantor/articles/1038214/
Вы упомянули в статье, что при высоких значений collapse_limit приходит OOM Killer из-за повышенной утилизации ОЗУ при планировании запроса. Может быть
geqoбыл отключен?Про 1С могу сказать так, что между ситуациями "все тормозит" и "работает быстро" или "приходит OOM Killer" и "теперь все ок" как раз и стоит разница в значениях по параметрам collapse_limit
Да причем тут рекомендации от фирмы 1С. Вы сами для прохождения теста 30К поставили *_collapse_limit = 20 и пишите об этом в статье. Зачем? Чем 8 не устроило?
https://habr.com/ru/companies/tantor/articles/1035568/comments/#comment_29978522
Я тоже написал инструмент Profiler для PostgreSQL, скоро выпущу статью.
Было неожиданно увидеть, что кому-то пришла аналогичная идея)
Войдут некоторые из доработок вывода EXPLAIN и ускорение планирование запросов
Это нормальный вид.
Установите данный параметр перед выполнением запроса (как делает платформа 1С) и тогда должны получить результат:
SET standard_conforming_strings=off;
Не совсем понял, что вы имеете ввиду под искажением? Стоит учитывать, что платформа 1С при каждом выполнении запроса устанавливает вот эти параметры, это может влиять на выбор плана запроса:
SET enable_mergejoin=off;
SET escape_string_warning=off;
SET standard_conforming_strings=off;
SET cpu_operator_cost=0.001;
Если вы выполняете запрос без установки этих параметров в pgadmin, то результат может быть другой
Сравнивать процессоры замерами расчёта себестоимости длительностью 30 секунд на демо-базе ерп - первый раз такое вижу.
И стоит добавить, что расчёт себестоимости как правило однопоточный процесс, поэтому ему важнее частота, а не количество ядер
А на сколько 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
Возможно здесь могло помочь кеширование плана запроса или оптимизация перебора вариантов соединения таблиц? Это не единственный такой пример, уже много таких случаев встречал