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.
It is hard to read the profile result, because these functions are nested together. For your example
18.22% postgres postgres [.] CachedPlanIsSimplyValid
Is little bit strange, and probably this is real bottleneck in your simple example, and maybe some work can be done there, because you assign just constant.
On second hand, your example is pretty unrealistic - and against any developer's best practices for writing cycles.
I think so we can look on PostGIS, where is some computing heavy routines in PLpgSQL, and we can look on real profiles.
Probably the most people will have benefit from these optimization.
>> > 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't have a function execute_stmt.
Right.