Hi, On Thu, Oct 29, 2026 at 12:30:08PM -0500, Sami Imseih wrote: > > What about retaining all strategies observed across rescans? The > > instrumentation > > could use a bitmask and EXPLAIN would report them as a list, for example: > > > > Buffer Access Strategies: normal, bulkread > > This makes sense,
Thanks for confirming. > but now it gets me thinking... > > If EXPLAIN reports multiple strategies for a node, I wonder whether we will > also need to break down the existing shared buffer counters by access > strategy. > > Something like: > > ``` > Buffers: shared hit=95 read=8482 written=12 > Strategy Buffers: normal hit=1, bulkread hit=94 read=8482 written=12 > ``` > > I think the breakdown should follow pg_stat_io's IOContext attribution. That > means shared hit/read, and probably written too, because those paths already > have an IOContext. I would leave dirtied out, since that does not seem to be > attributed to an IOContext today, based on my quick look at the code. > > These per-strategy counters could be tracked in pgBufferUsage and bubbled up > to EXPLAIN the same way the existing buffer counters are. > > What do you think? I agree that such a breakdown could be useful. It answers a different question though: the current patch reports which strategies were selected, while those counters would show how much buffer activity occurred under each strategy. For this first version, I’d prefer the patch series to focus on getting strategy reporting right while keeping the additional instrumentation relatively light. Also, pg_stat_get_backend_io(pg_backend_pid()) already provides backend wide counters broken down by I/O context. It lacks per plan node attribution but it may already cover some diagnostic use cases. So I’d prefer to consider that as a follow up. Does that make sense? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
