Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

On Mon, Jul 27, 2020 at 8:36 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> I don't know of a guideline for text format, but the issues I've raised for
> HashAgg and IncrSort are based on previous commits which change to "show field
> even if its value is zero" for non-text format:

But the non-text format for IncrSort shows about the same information
as sort, broken out by group. What's missing if you assume that sort
is the gold standard?

The objection to your argument from James (which could just as easily
apply to regular sort from earlier releases) is that accurate
information just isn't available as a practical matter. This is due to
tuplesort implementation limitations that cannot be fixed now. See the
comment block in tuplesort_get_stats() for an explanation. The hard
part is showing memory used by external sorts.

It's true that "Disk" is specifically shown by sort nodes output in
text explain format, but you're talking about non-text formats so
that's not really relevant

AFAICT sort (and IncrSort) don't fail to show a field value if it is
zero. Rather, they consistently show "space used" (in non-text
format), which can be either memory or disk space. Technically they
don't violate the letter of the law that you cite. (Though admittedly
this is a legalistic loophole -- the "space" value presumably has to
be interpreted according to different rules for programs that consume
non-text EXPLAIN output.)

Have I missed something?

--
Peter Geoghegan