Комментарии 7
Стоит похожая задача не из-за санкций, а из экономических соображений.
Внимательно прочитал статью, массу советов отложил в копилку.
Благодарю.
Но некоторые советы показались одинаково эффективными как для PostgreSQL, так и для MSSQL.
Конкретно:
Уход от большего числа временных таблиц процедурах в сторону CTE (обобщенное табличное выражение) / массивов.
Common Table Expressions в любом случае выигрывает по блокировкам, оптимизации памяти, времени компиляции и производительности по сравнению с временными таблицами. Безусловно, есть ограничения по индексации и отжираемой памяти, но это частные случаи, которые нужно рассматривать, балансируя между производительностью и ресурсами.
Уход от временных таблиц в сторону расширения pg_variables.
И с этим советом переход на Table Variables дает значительный прирост и на MS SQL.
Также, как и в первом случае, нужно балансировать между ограничениями, ресурсами и ожидаемым выигрышем.
Тащу сейчас подобный проект с ms sql на postgres. Процедур, примерно, 250+. Основная масса перенесена автоматически, но многое приходится переписывать руками.
Да, при переписывании один к одному чаще всего постгрес оказывается медленнее. Приходится вникать в логику (а там, бывает, чёрт ногу сломит) и переписывать по-другому. В некоторых случаях наоборот отказываться от CTE в пользу временных таблиц с добавлением индексов. Так как это система мониторинга, которая позволяет строить отчёты за разные периоды по разному набору параметров, то самая частая боль это построение почти одинаковых отчётов, которые нельзя просчитать заранее. Никогда не знаешь какой период данных выберет пользователь и по каким параметрам. За день - пара тысяч джоинов, за месяц - десяток миллионов. Иногда кажется, что проще было с нуля всё переписать по текущей документации.
Думаю, сдадим проект, как импортозамещение, и будем дальше уже заниматься конкретной оптимизацией.
Александр, спасибо за статью.
Уточните пожалуйста, каким автоматизированным средством производили конвертацию из TransactSQL в PL/pgSQL?
Привет! Спасибо за вопрос) Ответ от автора: "Я подключился к проекту на этапе уже реализованной предыдущими подрядчиками конвертации и коллеги частично использовали автоматизацию, но в результате стали все руками переписывать. Со своей стороны считаю, что на текущий момент, если бы возникла задача переноса нескольких десятков хранимых процедур с T-SQL на PL/pgSQL — то пошли бы реализовывать руками, поскольку зачастую доработка переведенного когда бывает даже сложнее, чем написание "с нуля". Мы сами уже в параллель оптимизации еще переписали около 70-80 хранимок."
Мы пользовались белорусским Конвертум-ом. Конвертирует на ура, если логика не сильно замудрёная. Как минимум сильно облегчает процесс.
Хехе завтра буду собеситься на вакансию под такую задачу... Спасибо за инфу)
Оптимизация хранимых процедур на PostgreSQL, мигрированных с MsSQL. Подходы к реализации, личный опыт