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

From Peter Geoghegan
Subject Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)
Date
Msg-id CAH2-Wzkg4irS+D_gD_kArkewXhQiL7SFLtjzxX25JRv4Mw4jow@mail.gmail.com
Whole thread Raw
In response to Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)  (Justin Pryzby <pryzby@telsasoft.com>)
Responses Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> Because filtering out zero values is exactly what's intended to be avoided for
> nontext output.
>
> I think checking whether the method was used should result in the same output,
> without the literal check for zero value (which itself sets a bad example).

It seems fine to me as-is. What about SORT_TYPE_TOP_N_HEAPSORT? Or any
other sort methods we add in the future?

The way that we flatten maxDiskSpaceUsed and maxMemorySpaceUsed into
"space used" on output might be kind of questionable, but it's
something that we have to live with for the foreseeable future. I
don't think that this is a bad example -- we don't output
maxDiskSpaceUsed or maxMemorySpaceUsed at the conceptual level.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Missing CFI in hlCover()?
Next
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module