Столкнулся с тем, что Pl/PgSQL процедура, котороая не содержит ничего, кроме операции присваивания в цикле, будучи запущенной одновременно в разных подключениях выполняется медленнее, чем в один поток. Тестировал на сервере с 20 ядрами - количество вызовов процедуры за единицу времени уменьшается экспоненциально при увеличении количества потоков:



Код процедур для теста выглядит следующим образом:




Первая процедура просто выполняет присваивание в цикле, вторая вызывает первую pCount раз и считает время. Если интересно, немного подробнее изложил тут .

Этому есть какое-нибудь объяснение? Может, блокировки какие или что-то ещё?

Melkijкросслинк https://www.postgresql.org/message-id/flat/CAN%3DgQ4Bc-CRKh91q38ApZd%2BB2iyB7ZDwusEPVq%2BiK8b8AMSG1A%40mail.gmail.com#CAN=gQ4Bc-CRKh91q38ApZd+B2iyB7ZDwusEPVq+iK8b8AMSG1A@mail.gmail.com]на hackers дискуссию
Спасибо, я постеснялся ).

Также я заметил, что это поведение сильно отличается в разных версиях:



Синяя - 9.2, желтая - 9.3, синяя - 9.5. В 9.6 почти то же, что и в 9.5, просто не успел построить график. На графике - количество присваиваний в секунду в зависимости от количества потоков.

Maxim Bogukbff7755aпропущено...

Спасибо, я постеснялся ).

Также я заметил, что это поведение сильно отличается в разных версиях:



Синяя - 9.2, желтая - 9.3, синяя - 9.5. В 9.6 почти то же, что и в 9.5, просто не успел построить график. На графике - количество присваиваний в секунду в зависимости от количества потоков.

По факту v := 1; это на самом деле некоторый select 1 into v; и начинаются игры с snapshot И тд.

Гонять вычисления на pl/pgsql нельзя он для склеивания sql Запросов а не для математики.

Для математики есть Pl/v8 pl/r pl/хрен-знает-что и тд на любой вкус.

PS: ссылка из обсуждения с графиками у меня дает 500 ошибку почему то.

Максим, добрый день, спасибо что ответили ).

Про то, что на каждое присваивание выполняется запрос я в курсе. В hackers я привёл следующую цепочку вызовов:

PLPGSQL_STMT_ASSIGN -> exec_stmt_assign() -> exec_assign_expr() -> exec_eval_expr() -> exec_run_select() -> SPI_execute_plan_with_paramlist() -> _SPI_execute_plan()

Далее действительно идут операции со снапшотами и прочим (PushActiveSnapshot(), PopActiveSnapshot()). Тут бы уже хотелось до истины добраться, просто уже любопытно стало. Хочу попробовать с помощью perf это попробовать выяснить. Если дело в снапшотах и lw блокировках, которые используются для работы с ними, тогда параллельное выполнение простого запроса даст такой же спад производительности - надо это проверить.

[quot Maxim Boguk]bff7755aпропущено...
PS: ссылка из обсуждения с графиками у меня дает 500 ошибку почему то.
Telegra.ph сегодня некстати сломался (см. твит ).

Статья доступна по этой ссылке.

Maxim Bogukbff7755a,
Тогда просто perf в руки и изучать.

Пока вышло вот что:

Картинка для 2 потоков:


Картинка для 10 потоков:


Я, если честно, большой разницы пока не вижу.

Также с помощью dtrace удалось узнать, что на каждое выполнение берётся одна легковесная блокировка, но ожиданий освобождения блокировок нету, даже если количество потоков превышает количество ядер CPU. Это наводит на мысль о приближении к пределу пропускной способности шины.