> > I still do not think we need to show all the strategies used here, at least > > not > > for the first version of this patch. What the user will care about most is > > which ring strategy was used, so if anything other than normal was used, > > that > > should take precedence. This should be documented. > > I had more thoughts about it and I think that both strategies are important, > as > both affect buffer replacement and therefore may impact the workload. > > 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, 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? -- Sami Imseih Amazon Web Services (AWS)
