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

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, James Coleman <jtc331(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)
Date: 2020-07-31 01:40:27
Message-ID: 20200731014027.GV20393@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 30, 2020 at 06:33:32PM -0700, Peter Geoghegan wrote:
> On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby <pryzby(at)telsasoft(dot)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?

Feel free to close it out. I'm satisfied that we've had a discussion about it.

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ZHAOWANCHENG 2020-07-31 01:42:42 Re: fixing pg_ctl with relative paths
Previous Message James Coleman 2020-07-31 01:39:35 Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort)