Re: Stack-based tracking of per-node WAL/buffer usage

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Lukas Fittl <lukas@fittl.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas@vondra.me>, Peter Smith <smithpb2250@gmail.com>, Zsolt Parragi <zsolt.parragi@percona.com>
Date: 2026-04-08T04:09:53Z
Lists: pgsql-hackers
Hi,

On 2026-04-07 15:27:45 -0700, Lukas Fittl wrote:
> On Tue, Apr 7, 2026 at 3:19 PM Andres Freund <andres@anarazel.de> wrote:
> I think renaming makes sense - both to make sure extensions reconsider
> how they use it, and because "totaltime" is a bad name anyway, because
> its not just about timing (and hasn't been for many releases).
> 
> "query_instr[_options]" seems reasonable to me, although we could drop
> the "query_" since it'd be "queryDesc->query_instr" vs
> "queryDesc->instr".

Done that way.

I earlier pushed 0002 too.


> > Kinda wonder about having
> >   EXPLAIN (ANALYZE BUFFERS totals_only, WAL totals_only) ...;
> >
> > in plenty cases that'd be all one needs, at substantially lower cost.
> 
> True. I don't like the name "totals_only", but I like the concept.

I spent all of three seconds coming up with it... :)


> Today someone has to go to pg_stat_statements to get just the total
> numbers, without running them for all nodes with EXPLAIN ANALYZE (and
> incurring its overhead).

Yep.

Greetings,

Andres Freund



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. instrumentation: Allocate query level instrumentation in ExecutorStart

  2. instrumentation: Move ExecProcNodeInstr to allow inlining

  3. instrumentation: Separate per-node logic from other uses

  4. instrumentation: Separate trigger logic from other uses

  5. instrumentation: Rename INSTR_TIME_LT macro to INSTR_TIME_GT

  6. instrumentation: Keep time fields as instrtime, convert in callers