Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
Date
Msg-id CAH2-Wz=QjO7vGrrZQ3VWsatbujFzmyH4GtBKXFTUpVVCW3RFEg@mail.gmail.com
Whole thread Raw
In response to Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.
List pgsql-hackers
On Mon, Jul 27, 2020 at 8:36 PM Justin Pryzby <pryzby@telsasoft.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



pgsql-hackers by date:

Previous
From: David Pirotte
Date:
Subject: Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?
Next
From: "David G. Johnston"
Date:
Subject: Re: PG 13 release notes, first draft