Re: Inlining of couple of functions in pl_exec.c improves performance

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Inlining of couple of functions in pl_exec.c improves performance
Date: 2020-06-01 06:56:26
Message-ID: CAFj8pRCgQYKk0os1hQiR42K6qh6Eb48us_Rw21KtGoJ-dX6oHA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

po 1. 6. 2020 v 8:15 odesílatel Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>
napsal:

> On Sat, 30 May 2020 at 11:11, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-06-01 06:58:31 Re: Internal key management system
Previous Message Masahiko Sawada 2020-06-01 06:34:10 Re: Internal key management system