Re: Inlining of couple of functions in pl_exec.c improves performance
От | Amit Khandekar |
---|---|
Тема | Re: Inlining of couple of functions in pl_exec.c improves performance |
Дата | |
Msg-id | CAJ3gD9f6Zz56y+CBr-wVJVyfF+1VaeH0_BZqvbC1vCWuux7cDg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inlining of couple of functions in pl_exec.c improves performance (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Inlining of couple of functions in pl_exec.c improves performance
|
Список | pgsql-hackers |
On Sat, 30 May 2020 at 11:11, Pavel Stehule <pavel.stehule@gmail.com> wrote: > I think so the effect of these patches strongly depends on CPU and compile I quickly tried pi() with gcc 10 as well, and saw more or less the same benefit. I think, we are bound to see some differences in the benefits across architectures, kernels and compilers; but looks like some benefit is always there. > but it is micro optimization, and when I look to profiler, the bottle neck is elsewhere. Please check the perf numbers in my reply to Michael. I suppose you meant CachedPlanIsSimplyValid() when you say the bottle neck is elsewhere ? Yeah, this function is always the hottest spot, which I recall is being discussed elsewhere. But I always see exec_stmt(), exec_assign_value as the next functions. >> > patch 0002 it is little bit against simplicity, but for PLpgSQL with blocks structure it is correct. >> >> Here, I moved the exec_stmt code into exec_stmts() function because >> exec_stmts() was the only caller, and that function is not that big. I >> am assuming you were referring to this point when you said it is a bit >> against simplicity. But I didn't get what you implied by "but for >> PLpgSQL with blocks structure it is correct" > > > Nested statement in PLpgSQL is always a list of statements. It is not single statement ever. So is not too strange don'thave a function execute_stmt. Right.
В списке pgsql-hackers по дате отправления: