Horton

Re: plan cache overhead on plpgsql expression

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavel Stehule <pavel.stehule@gmail.com>, Amit Langote <amitlangote09@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-03-25T20:32:15Z
Lists: pgsql-hackers 
On Sat, Mar 21, 2020 at 2:24 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> With this patch, perf shows the hotspots on Pavel's original example
> as being
>
> +   19.24%    19.17%         46470  postmaster       plpgsql.so                   [.] exec_eval_expr
> +   15.19%    15.15%         36720  postmaster       plpgsql.so                   [.] plpgsql_param_eval_var
> +   14.98%    14.94%         36213  postmaster       postgres                     [.] ExecInterpExpr
> +    6.32%     6.30%         15262  postmaster       plpgsql.so                   [.] exec_stmt
> +    6.08%     6.06%         14681  postmaster       plpgsql.so                   [.] exec_assign_value

That's pretty sweet. As you say, there's probably some way to
eliminate some of the non-plancache overhead, but it's still a big
improvement.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Rearrange validity checks for plpgsql "simple" expressions.

  2. Improve performance of "simple expressions" in PL/pgSQL.

  3. Ensure that plpgsql cleans up cleanly during parallel-worker exit.