| 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: | Whole Thread | Raw Message | 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
| 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) |