On Wed, Feb 12, 2025 at 5:10 AM Ilia Evdokimov <ilya.evdoki...@tantorlabs.com> wrote: > I think the idea of keeping two significant digits after the decimal > point is quite reasonable. The thing is, rows=0.000001 or something > similar can only occur when loops is quite large. If we show the order > of magnitude in rows, it will be easier for the user to estimate the > order of total rows. For example, if we see this: > > rows=0.000056 loops=4718040 > > the user can quickler approximate the order of total rows for analyzing > the upper levels of the query.
I agree that showing 2 digits after the decimal point in all cases is not ideal, but I suggest that we take a practical approach. Figuring out dynamically what number of decimal digits to display in each case sounds complicated and we may spend a bunch of time arguing about the details of that and get nothing committed. If we just show 2 digits after the decimal point, it will not be perfect, but it will be 10^2 times better than what we have now. If I'm honest, what I actually think we should do is stop dividing values by nloops before printing them out. Every time I'm looking at a quantity that has been divided by nloops, the very first thing I do is try to figure out what the original value was. The whole reason I want to display at least a couple of decimal digits here is so that I can do that more accurately, but of course the dream would be not having to reverse engineer it like that at all. However, I expect fierce opposition to that idea, and no matter how misguided I may think that opposition might be, a patch in the tree is worth two in the CommitFest. -- Robert Haas EDB: http://www.enterprisedb.com
