Когда я работал в Магните, то мы на основе БСП сделали свою подсистему, которая позволяла управлять индексами в пользовательском режиме. Было даже автоматическое создание в процедурах обработчиков обновления, если индекс был удален в результате реструктуризации таблицы...
Кмк, это слабоприменимо. В норме там должно быть попадание в индексы, а в них порядком полей не получится жонглировать.
Для 1С характерно соединение таблиц по большому количеству полей, поэтому при таких соединениях не всегда можно найти покрывающий условия такого соединения индекс. Вот тут оптимизация и будет полезна. Что касается настроек индексов, то в платформе 1С 8.3.26 завезли наконец-то возможность создавать кастомные индексы, что конечно хорошо.
Это результаты, которые мы повторили на нашей СУБД Tantor Postgres.
Что касается количества активных сеансов, то они держались примерно на одном уровне не более 50, при этом в состоянии idle было около 700-1000. Но это не зачит, что мы запустили тест и сразу получили хороший результат. Сначала количество активных сеансов подскакивало и до нескольких тысяч, и это вызвало у желание у моих коллег не-1Сников использовать упомянутый вами pg_bouncer, но у 1С свой собственный пулер и подключение pg_bouncer нам бы никакого эффекта не дало, т.к. целью теста была не только стабильная работа 30К пользователей, но и их быстрая работа в 1С, без тормозов. А причин у большого количества активных пользователей было несколько и это решалось доработкой внутренних механизмов Tantor Postgres: расшивали узкие места, связанные в основном с работой временных таблиц (об этом подробно в докладе и расскажу 11 октября).
В версии 1 это rule-based, а в версии 2 будет уже cost-based. В самом Postgresql реализован простейший PPD - https://infostart.ru/1c/articles/2142833/#Predicate pushdown в Postgres При этом по исходному коду там много ограничений его применения. Я думаю, что просто нет ставки на улучшение планировщика для аналитических запросов, и каждая такая доработка действительно очень сложна в реализации. При этом по коммерческим СУБД есть описание в патентах или научных статьях как реализована та или иная фича. Вот пример еще одной фичи, которая в 1С встречается, и мы ее себе "портировали", но пока не выпустили - https://nenadnoveljic.com/blog/disjunctive-subquery-optimization/
У нас реализация нацелена на использование в 1С, поэтому оконные и рекурсивные CTE мы не рассмтривали, а вот с lateral планируем далее реализовать, т.к. в 1С будет эффект. И да, спасибо за указанную статью, она была, можно сказать, вдохновением для реализации JPPD в нашей СУБД :)
из-за отсутствия в PG аналогов временных таблиц MS SQL
В PG есть временные таблицы, платформа 1С работает также кроме нюанса с использованием механизма копий баз данных, когда на реплике нельзя создавать временные таблицы, но это решаемо.
Мы делимся с сообществом некоторыми наработками, исправлениями багов, но провести в релиз ванильного postgres сложные оптимизации, доработки непросто.
Когда я работал в Магните, то мы на основе БСП сделали свою подсистему, которая позволяла управлять индексами в пользовательском режиме. Было даже автоматическое создание в процедурах обработчиков обновления, если индекс был удален в результате реструктуризации таблицы...
Для 1С характерно соединение таблиц по большому количеству полей, поэтому при таких соединениях не всегда можно найти покрывающий условия такого соединения индекс. Вот тут оптимизация и будет полезна.
Что касается настроек индексов, то в платформе 1С 8.3.26 завезли наконец-то возможность создавать кастомные индексы, что конечно хорошо.
Это результаты, которые мы повторили на нашей СУБД Tantor Postgres.
Что касается количества активных сеансов, то они держались примерно на одном уровне не более 50, при этом в состоянии idle было около 700-1000.
Но это не зачит, что мы запустили тест и сразу получили хороший результат. Сначала количество активных сеансов подскакивало и до нескольких тысяч, и это вызвало у желание у моих коллег не-1Сников использовать упомянутый вами pg_bouncer, но у 1С свой собственный пулер и подключение pg_bouncer нам бы никакого эффекта не дало, т.к. целью теста была не только стабильная работа 30К пользователей, но и их быстрая работа в 1С, без тормозов.
А причин у большого количества активных пользователей было несколько и это решалось доработкой внутренних механизмов Tantor Postgres: расшивали узкие места, связанные в основном с работой временных таблиц (об этом подробно в докладе и расскажу 11 октября).
У вас на уровне приложения (isFusion) считается стоимость выполнения и выбирается оптимальный план?
В версии 1 это rule-based, а в версии 2 будет уже cost-based.
В самом Postgresql реализован простейший PPD - https://infostart.ru/1c/articles/2142833/#Predicate pushdown в Postgres
При этом по исходному коду там много ограничений его применения. Я думаю, что просто нет ставки на улучшение планировщика для аналитических запросов, и каждая такая доработка действительно очень сложна в реализации.
При этом по коммерческим СУБД есть описание в патентах или научных статьях как реализована та или иная фича. Вот пример еще одной фичи, которая в 1С встречается, и мы ее себе "портировали", но пока не выпустили - https://nenadnoveljic.com/blog/disjunctive-subquery-optimization/
У нас реализация нацелена на использование в 1С, поэтому оконные и рекурсивные CTE мы не рассмтривали, а вот с lateral планируем далее реализовать, т.к. в 1С будет эффект.
И да, спасибо за указанную статью, она была, можно сказать, вдохновением для реализации JPPD в нашей СУБД :)
В PG есть временные таблицы, платформа 1С работает также кроме нюанса с использованием механизма копий баз данных, когда на реплике нельзя создавать временные таблицы, но это решаемо.
В Tantor Postgres реализован JPPD и не только - https://habr.com/ru/companies/tantor/articles/924978/
Оптимизация "размер пула временных таблиц" относится к платформе 1С, а не к PG
Согласен, что это противоречит методологии, но при каждой миграции с MS SQL приходится сталкиваться с такими запросами.