On Tue, Jun 2, 2026 at 4:29 PM Sami Imseih <samimseih@gmail.com> wrote:
>
> > >> 0001: Use the new Instrumentation struct to handle WAL and Buffer usage together
> > >
> > > This one is a straightforward refactor. Only comment is to remove the bare block
> > >
> > > - InstrEndParallelQuery(&buffer_usage[ParallelWorkerNumber],
> > > -
> > > &wal_usage[ParallelWorkerNumber]);
> > > + {
> > > + Instrumentation *worker_instr;
> > > +
> > > + worker_instr = shm_toc_lookup(toc,
> > > PARALLEL_KEY_INSTRUMENTATION, false);
> > > + InstrEndParallelQuery(&worker_instr[ParallelWorkerNumber]);
> > > + }
> >
> > Instrumentation is a structure larger than WalUsage and BufferUsage
> > combined, and we don't care about all these other fields for the
> > parallel workers. Sure, this cuts code, but this also increases the
> > DSM and memory footprint.
>
> The difference is 192 bytes per worker; 360 bytes for Instrumentation
> - 168 bytes
> for removing BufferUsage and WalUsage. Even with 32 parallel workers ( probably
> the extreme case ) that is ~6 KB, which is negligible compared to the code
> cleanup.
Hmm, thanks for running the numbers!
I agree its not substantial, but its also not nothing - so I see
Michael's point. I think the largest difference here is the fact that
WalUsage and BufferUsage are repeated - that is something that would
no longer be necessary once/if we go with the stack-based
instrumentation approach. When I had this patch in the other patch
series, it was after a refactoring that made the overhead much
smaller.
Maybe for now I can re-order this patch series to lead with the other
patches, and we could defer this part a bit until we have clarity what
we're doing re: stack-based instrumentation.
I'll respond on the other comments separately later this week. Thanks
to you both for the quick feedback!
Thanks,
Lukas
--
Lukas Fittl
