Результатов тестирования на 30к пользователей для MS действительно не встречали, но более скромные нагрузочные тесты регулярно проводятся. Недавнее исследование одного из партнёров 1С показало, что на их тестах APDEX у MS SQL Server 2022 ниже, чем у любого из исследуемых вендоров PostgreSQL, в то время как результат MS SQL Server 2019 соответствует средне-рыночным показателям.
Другие СУБД редко попадают в подобные исследования, поскольку MS SQL и PostgreSQL самые популярные в использовании под 1С.
За такую чудесную отсылку особенная благодарность :)
А если Роман Фролов невероятно опечален, что книгу Егора Рогова унёс с собой Евгений Моргунов (жуть как много имён в одном предложении), придётся ему продолжить традицию очно посещать конференции, чтобы у вселенной был шанс исправить сию несправедливость.
В тему сохранения долгих запросов (и не только) могу добавить рекомендацию почитать про pg_profile. А для облегчения чтения логов - pgBadger. Вдруг кому-нибудь окажется полезным.
Не обязательно. Тут может быть несколько подходов:
1) Если планировщик не оптимально выбрал метод из-за устаревшей статистики по некоторой таблице, может помочь своевременный запуск ANALYSE по этой таблице перед запуском запроса. Часто его использовать не стоит - может долго выполняться, но с некоторой периодичностью может быть полезно.
2) Раз выяснили, что отключение Nested Loop хорошо работает для этого запроса (несмотря на большое число операций в нём), можно «прилепить» этот SET к запросу (SET LOCAL внутри транзакции).
3) Самый элегантный способ, чтобы не переписывать запрос и не делать дополнительных действий: добавить к нему hint.
Расширение pg_hint_plan с открытым исходным кодом и совместимо со всеми поддерживаемыми версиями PostgreSQL. Инструкция по установке из официального репозитория В Pro версию тоже входит, поэтому русскоязычная документация по модулю расположена в разделе enterprise
Результатов тестирования на 30к пользователей для MS действительно не встречали, но более скромные нагрузочные тесты регулярно проводятся. Недавнее исследование одного из партнёров 1С показало, что на их тестах APDEX у MS SQL Server 2022 ниже, чем у любого из исследуемых вендоров PostgreSQL, в то время как результат MS SQL Server 2019 соответствует средне-рыночным показателям.
Другие СУБД редко попадают в подобные исследования, поскольку MS SQL и PostgreSQL самые популярные в использовании под 1С.
Кажется, нашла причину проблемы. С августовского релиза всё заработает))
За такую чудесную отсылку особенная благодарность :)
А если Роман Фролов невероятно опечален, что книгу Егора Рогова унёс с собой Евгений Моргунов (жуть как много имён в одном предложении), придётся ему продолжить традицию очно посещать конференции, чтобы у вселенной был шанс исправить сию несправедливость.
pgpro_stats входит в Postgres Pro Standart и Enterprise
В ванильной версии только pg_stat_statements
Может, установлен флаг?
--noexplain : do not process lines generated by auto_explainСпасибо!
В тему сохранения долгих запросов (и не только) могу добавить рекомендацию почитать про pg_profile. А для облегчения чтения логов - pgBadger.
Вдруг кому-нибудь окажется полезным.
Не обязательно. Тут может быть несколько подходов:
1) Если планировщик не оптимально выбрал метод из-за устаревшей статистики по некоторой таблице, может помочь своевременный запуск ANALYSE по этой таблице перед запуском запроса. Часто его использовать не стоит - может долго выполняться, но с некоторой периодичностью может быть полезно.
2) Раз выяснили, что отключение Nested Loop хорошо работает для этого запроса (несмотря на большое число операций в нём), можно «прилепить» этот SET к запросу (SET LOCAL внутри транзакции).
3) Самый элегантный способ, чтобы не переписывать запрос и не делать дополнительных действий: добавить к нему hint.
Расширение pg_hint_plan с открытым исходным кодом и совместимо со всеми поддерживаемыми версиями PostgreSQL. Инструкция по установке из официального репозитория
В Pro версию тоже входит, поэтому русскоязычная документация по модулю расположена в разделе enterprise