I guess what I would be looking for in stats would be a way to tell what the bandwidth, latency, and queue depth is. Ideally one day broken down by relation/index and pg_stat_statement record.
I think seeing the actual in flight async requests in a connection is probably not going to be very useful in production. It's very low level and in production the user is just going to find that overwhelming detail. It is kind of cool to see the progress in sequential operations but I think that should be solved in a higher level way than this anyways. What we need to calculate these values would be the kinds of per-op stats nfsiostat uses from /proc/self/mountstats: https://utcc.utoronto.ca/~cks/space/blog/linux/NFSMountstatsNFSOps So number of async reads we've initiated, how many callbacks have been called, total cumulative elapsed time between i/o issued and i/o completed, total bytes of i/o initiated, total bytes of i/o completed. As well a counter of requests which returned errors (eof? i/o error?) If there are other locks or queues internally to postgres total time spent in those states. I have some vague idea that we should have a generic infrastructure for stats that automatically counts things associated with plan nodes and automatically bubbles that data up to the per-transaction, per-backend, per-relation, and pg_stat_statements stats. But that's a whole other ball of wax :)
