Re: Report buffer access strategies in EXPLAIN

> > 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)