Thank you Guillaume, and nice work! I tried to see if there was anywhere else in the documentation that would need updating, but it looks like you covered everywhere already.
> I'm with Robert in that I've not found the buffer counts to be all that useful most of the time.
I find the buffer counts especially helpful for educating newer folks on why things are slow, even when they are not necessary for spotting the issue (for more advanced users). One of my hopes is that by educating and empowering newer users on how I/O relates to performance issues, fewer cases will get escalated to more experienced folks.
> the cases I've seen most recently are those where the output is mind-numbingly long already.
Are you mostly seeing query plans that have stumped other people already (eg second or third line support), so perhaps seeing more complex plans than the average user?
Both Depesz[1] and Tensor[2] have archives of publicly submitted plans, which I found helpful for checking how slow plans look for users of those tools. I have a similar archive, and while we do not publish them (and there are plenty of huge plans) it also suggests that the majority of slow plans people are reviewing have fewer than 20 nodes.
I realise it’s optimistic to think that the time experienced hackers would lose having to sift through longer plans would be gained back by having to do so less often, but I thought it was worth raising as part of the aim.
I also looked into the Slow Query Questions page on the wiki that we ask people to review before posting to pgsql-performance, and noticed that has suggested requesting buffers for the past 12 years[3].
