public inbox for [email protected]
help / color / mirror / Atom feedFrom: Lukas Fittl <[email protected]>
To: PostgreSQL Hackers <[email protected]>
To: Andres Freund <[email protected]>
Cc: Peter Smith <[email protected]>
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
Date: Sat, 7 Mar 2026 20:31:07 -0800
Message-ID: <CAP53PkxVYGEfK-eNWJSMEa8-F1bWQKWWacJUrHyxkd3G0hrs9g@mail.gmail.com> (raw)
In-Reply-To: <CAP53PkxrmpECzVFpeeEEHDGe6u625s+YkmVv5-gw3L_NDSfbiA@mail.gmail.com>
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>
On Sat, Mar 7, 2026 at 8:27 PM Lukas Fittl <[email protected]> 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/[email protected]
--
Lukas Fittl
view thread (44+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Stack-based tracking of per-node WAL/buffer usage
In-Reply-To: <CAP53PkxVYGEfK-eNWJSMEa8-F1bWQKWWacJUrHyxkd3G0hrs9g@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox