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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)
Дата
Msg-id CAH2-Wzkg4irS+D_gD_kArkewXhQiL7SFLtjzxX25JRv4Mw4jow@mail.gmail.com
обсуждение исходный текст
Ответ на Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)  (Justin Pryzby <pryzby@telsasoft.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Missing CFI in hlCover()?
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: new heapcheck contrib module