30 тыс. строк кода или как мы переходили с Oracle на PostgreSQL с помощью утилиты Ora2Pg 23.0 / Comments / Habr

edo1h Jun 6 2022 at 20:51

Убрали переменные из непосредственных запросов к таблицам.

хм, а зачем?

проверил похожий код, работает

create table t_from (x1 int, x2 int);
create table t_to(x1 int, x2 int, x3 int);

CREATE FUNCTION f_test(x3 int) RETURNS void
    LANGUAGE plpgsql SECURITY DEFINER
    AS $_$
  begin
    insert into t_to (x1, x2, x3) select x1, x2, x3 from t_from;
  end;
$_$;

insert into t_from (x1, x2) values (1000,1001);
select f_test(777);
select * from t_to;

На момент завершения проекта среднее время выполнения процедур в PostgreSQL по сравнению с Oracle увеличилось в 1.5 раза.

вот это если бы расписали, было бы очень круто (медленнее выполнение запросов или plpgsql, нашли ли какие-то узкие места)

anaum0v Jun 8 2022 at 14:09

хм, а зачем?

Согласен, сейчас, по-новому взглянув на вопрос стало ясно что необходимость убирать переменные из непосредственных запросов к таблицам как таковая действительно отсутствует. Например, при наличии предложения GROUP BY в заблуждение вводит всплывающая подсказка "Column 'x3' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause" при написании кода в IDE от JetBrains - в частности резюмируя можно сказать что варианты написания (1, 2 и 3) имеют место быть и полностью валидны, причем варианты 2 и 3 по умолчанию не выдают синтаксических ошибок.

-- 2
create or replace function f_test(x3 int) returns void
    language plpgsql
    security definer
as
$_$
begin
    insert into t_to (x1, x2, x3) select x1, x2, x3 from t_from group by x1, x2, x3;
end;
$_$;


-- 3
create or replace function f_test(x3 int) returns void
    language plpgsql
    security definer
as
$_$
begin
    insert into t_to (x1, x2, x3)
    select a.*, x3
    from (select x1, x2
          from t_from
          group by x1, x2) a;
end;
$_$;

вот это если бы расписали, было бы очень круто (медленнее выполнение запросов или plpgsql, нашли ли какие-то узкие места)

Что касается вопросов производительности, то сравнивать СУБД по данному критерию достаточно сложно, поэтому для себя мы объективно оцениваем производительность по времени выполнения ряда самых ресурсоемких процедур при идентичных входных условиях (одинаковое «железо», одинаковые исходные данные).

Как уже было отмечено в статье наиболее "затратными" получились различного рода манипуляции между таблицами: когда большие массивы данных претерпевая изменения переходят из таблицы в таблицу.

Найденное же незначительное количество узких мест не имеет признака массовости и, соответственно, принятые решения не должны трактоваться как "руководства к действию" - как правило получается довольно творческий процесс переписывания как со стороны исходного кода (с учетом построения возможно новых планов запросов), так и со стороны внесения соответствующих правок в структуру базы данных (пересмотр индексов к таблицам и т.д.).

gelonso Jun 21 2022 at 17:57

Огонь! А пробовали миграцию на Postgres Pro?

anaum0v Jul 5 2022 at 23:36

нет, не пробовали, так как изначально такой задачи у нас не стояло, однако методические рекомендации по подготовке заявок на включение ПО в Единый реестр https://ru-ikt.ru/metodicheskiye_rekomendatsi/ все же рекомендуют перейти на российский аналог PostgreSQL - PostgresPro - поэтому данный вопрос находится в проработке у нашей команды и возможно мы попробуем миграцию на PostgresPro в самой ближайшей перспективе, по итогу дадим обратную связь.