Это результаты, которые мы повторили на нашей СУБД 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С работает также кроме нюанса с использованием механизма копий баз данных, когда на реплике нельзя создавать временные таблицы, но это решаемо.
Это результаты, которые мы повторили на нашей СУБД 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 приходится сталкиваться с такими запросами.