The performance cost of pl/pgsql exception block in Postgres

One of the languages that Postgres offers for writing stored procedures is pl/pgsql. One of it's features is exception block that is used to catch errors raised in a code block. Appropriate use of this construct can improve code reliability, but when overused it can lead to decreased performance.

The official documentation says the following:
https://www.postgresql.org/docs/current/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING

A block containing an EXCEPTION clause is significantly more expensive to enter and exit than a block without one. Therefore, don't use EXCEPTION without need.

But what exactly significantly more expensive means? Is it 50% slower? 100% slower? Let's check this out.

First, we'll need a table with some data. I'll use the following one:

create table ops(id bigint, body jsonb);

I filled this table with about 20 million rows. Each row contains some json data in body column. The exact structure varies, but there's a common field: all stored jsons are objects containing value key.

Having this, I'll do a simple processing of that data.
For each row in that table I will invoke the following function:

create or replace function process_op(op ops)
returns void volatile language 'plpgsql'
as $$
begin
  insert into data(id, body) select op.id, op.body->>'value';
end;
$$;

This basically extracts the value element and writes it into a separate table data, which has the following structure:

create table data(id bigint, body text);

I will compare obtained results with a second scenario, which will be identical to the first one, with the exception that the following function will be used instead:

create or replace function process_op_exn(op ops)
returns void volatile language 'plpgsql'
as $$
begin
  begin
    insert into data(id, body) select op.id, op.body->>'value';
  exception WHEN division_by_zero then
  end;
end
$$;

The only difference is extra exception block that catches specified exception type. The exact type doesn't matter here, because it will never occur. I have to specify it nonetheless, so it'll be division_by_zero.

Now, here's the script that will do the timing of our processing:

#!/bin/sh
sql() {
    psql -c "$@" ex
}

trunc() {
    sql 'truncate data'
}

trunc
echo 'process_op'
sql 'set jit=off; explain analyze select process_op(op) from ops as op'

trunc
echo 'process_op_exn'
sql 'set jit=off; explain analyze select process_op_exn(op) from ops as op'

This script will use an empty database ex that only contains our two functions and the input and output tables. Before each test, the output table is truncated.
Note that jit is disabled. It's because it'd just introduce additional variance in timing results.
I'll run this script 10 times and collect the time reported by explain analyze.

Here's the times I got on my machine: (PostgreSQL 14.10 (Ubuntu 14.10-0ubuntu0.22.04.1))

I repeated the measurements for half of the data size (so about 10 million rows):

And here's measurements repeated for double the data size (about 40 million rows):

The timings are pretty consistent and we clearly see that the function with exception block takes longer time to complete.
The slowdown due to the exception block is about 35-38%. This overhead is definitely noticeable, but it'll of course depend on the work load. The more work is performed in such block, the less noticeable it'll be. The important part is that the performance hit is taken even if the exception is never raised.

EDIT 02-02-2024: Added measurements for half and double data set sizes.