On Tue, Jun 2, 2026 at 4:29 PM Sami Imseih <[email protected]> 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
