Re: Stack-based tracking of per-node WAL/buffer usage - Mailing list pgsql-hackers

On Sat, Mar 7, 2026 at 8:27 PM 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.f46nbqkdhbutzqdg@alap3.anarazel.de


--
Lukas Fittl