On Tue, Nov 21, 2017 at 12:55 PM, Robert Haas <robertmh...@gmail.com> wrote: > I agree. > > I have been of the opinion all along that progress monitoring needs to > report facts, not theories. The number of tuples read thus far is a > fact, and is fine to report for whatever value it may have to someone.
That makes a lot of sense to me. I sometimes think that we're too hesitant to expose internal information due to concerns about it being hard to interpret. I see wait events as bucking this trend, which I welcome. We see similar trends in the Linux kernel, with tools like perf and BCC/eBPF now being regularly used to debug production issues. > The number of tuples that will be read in the future is a theory, and > as you say, progress monitoring is most likely to be used in cases > where theory and practice ended up being very different. You hit the nail on the head here. It's not that these things are not difficult to interpret - the concern itself is justified. It just needs to be weighed against the benefit of having some instrumentation to start with. People are much more likely to complain about obscure debug information, which makes them feel dumb, than they are to complain about the absence of any instrumentation, but I still think that the latter is the bigger problem. Besides, you don't necessarily have to understand something to act on it. The internals of Oracle are trade secrets, but they were the first to have wait events, I think. At least having something that you can Google can make all the difference. -- Peter Geoghegan