MIME-Version: 1.0
References: 
 <CAP53PkzdBK8VJ1fS4AZ481LgMN8f9mJiC39ZRHqkFUSYq6KWmg@mail.gmail.com>
 <h7zq426fhzt3oqkps53qxfwl3dlz3ifcwqmybuvxntlcaqwb33@m6huopxovgle>
 <CAP53Pkw1RpyAVsvJwUOMgGnVoQUibMk+EB+w-8WqY8kzsC4WjA@mail.gmail.com>
 <CAP53Pkz-BmkLFJ+sAcr8H1sBPtWp8WYGzorH9yw+W5Tn0yH0sg@mail.gmail.com>
 <mflexfbmbkmql5snr322ldu72dfnjr2dntxx3ippaz4tcso7vl@zmxxgiws3qux>
 <CAP53PkzZ3UotnRrrnXWAv=F4avRq9MQ8zU+bxoN9tpovEu6fGQ@mail.gmail.com>
 <k2uxwancbi5blb2duny3kbuz667m47hqc4jv7xstlx3yyzcd3a@fjqww6avalt3>
 <CAHut+Put94CTpjQsqOJHdHkgJ2ZXq+qVSfMEcmDKLiWLW-hPfA@mail.gmail.com>
 <CAP53PkyOvXC7pWAiamvWth_JNeb=isrxX+PJT0pw_Hw5Czzf+Q@mail.gmail.com>
 <CAP53PkzGbyeJMLDAcvMRgzXPXYsYXZr3SBg0UwhfkYjqu8oK_g@mail.gmail.com>
 <CAP53PkxrmpECzVFpeeEEHDGe6u625s+YkmVv5-gw3L_NDSfbiA@mail.gmail.com>
In-Reply-To: 
 <CAP53PkxrmpECzVFpeeEEHDGe6u625s+YkmVv5-gw3L_NDSfbiA@mail.gmail.com>
From: Lukas Fittl <lukas@fittl.com>
Date: Sat, 7 Mar 2026 20:31:07 -0800
Message-ID: 
 <CAP53PkxVYGEfK-eNWJSMEa8-F1bWQKWWacJUrHyxkd3G0hrs9g@mail.gmail.com>
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Andres Freund <andres@anarazel.de>
Cc: Peter Smith <smithpb2250@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAP53PkxVYGEfK-eNWJSMEa8-F1bWQKWWacJUrHyxkd3G0hrs9g%40mail.gmail.com>
Precedence: bulk

On Sat, Mar 7, 2026 at 8:27=E2=80=AFPM Lukas Fittl <lukas@fittl.com> wrote:
> Example (default shared_buffers, runtimes are best out of 3-ish):
>
> CREATE TABLE lotsarows(key int not null);
> INSERT INTO lotsarows SELECT generate_series(1, 50000000);
> VACUUM FREEZE lotsarows;
>
> 250ms actual runtime (no instrumentation)
>
> BUFFERS OFF, TIMING OFF:
> 295ms master
> 295ms with stack-based instrumentation only (v7/0005) -- no change
> because BUFFERS OFF
> 260ms with ExecProcNodeInstr inlining work (v7/0006)
>
> BUFFERS ON, TIMING OFF:
> 380ms master
> 305ms with stack-based instrumentation only (v7/0005)
> 280ms with ExecProcNodeInstr inlining work (v7/0006)
>
> In summary: For BUFFERS ON, we're going from 52% overhead in this
> stress test, to 12% overhead (22% without the ExecProcNodeInstr
> change). With rows instrumentation only, we go from 18% to 3%
> overhead.

Erm, and I forgot the query here, this is testing "SELECT count(*)
FROM lotsarows;", just like over in [0].

Thanks,
Lukas

[0]: https://www.postgresql.org/message-id/flat/20200612232810.f46nbqkdhbut=
zqdg@alap3.anarazel.de


--
Lukas Fittl