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

2020-07-30 Thread Peter Geoghegan
On Thu, Jul 30, 2020 at 6:40 PM Justin Pryzby wrote: > Feel free to close it out. I'm satisfied that we've had a discussion about > it. Closed it out. -- Peter Geoghegan

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

2020-07-30 Thread Peter Geoghegan
On Thu, Jul 30, 2020 at 6:39 PM James Coleman wrote: > I very much do not like this approach, and I think it's actually > fundamentally wrong, at least for the memory check. Quicksort is not the only > option that uses memory. For now, there's only one option that spills to disk > (external mer

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

2020-07-30 Thread Justin Pryzby
On Thu, Jul 30, 2020 at 06:33:32PM -0700, Peter Geoghegan wrote: > On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby 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

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

2020-07-30 Thread James Coleman
On Thu, Jul 30, 2020 at 8:22 PM Justin Pryzby wrote: > On Wed, Jul 29, 2020 at 09:18:44PM -0700, Peter Geoghegan wrote: > > On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby > wrote: > > > So my 2ndary suggestion is to conditionalize based on the method > rather than > > > value of space used. > > >

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

2020-07-30 Thread Peter Geoghegan
On Thu, Jul 30, 2020 at 5:22 PM Justin Pryzby 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

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

2020-07-30 Thread Justin Pryzby
On Wed, Jul 29, 2020 at 09:18:44PM -0700, Peter Geoghegan wrote: > On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby wrote: > > So my 2ndary suggestion is to conditionalize based on the method rather than > > value of space used. > > What's the advantage of doing it that way? Because filtering out z

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-29 Thread Peter Geoghegan
On Wed, Jul 29, 2020 at 9:05 PM Justin Pryzby wrote: > So my 2ndary suggestion is to conditionalize based on the method rather than > value of space used. What's the advantage of doing it that way? -- Peter Geoghegan

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-29 Thread Justin Pryzby
On Wed, Jul 29, 2020 at 08:35:08PM -0700, Peter Geoghegan wrote: > 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 o

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-29 Thread Peter Geoghegan
On Mon, Jul 27, 2020 at 8:36 PM Justin Pryzby 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 IncrSor

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-28 Thread David Rowley
On Mon, 27 Jul 2020 at 14:54, Justin Pryzby wrote: > > On Mon, Jul 27, 2020 at 10:48:45AM +1200, David Rowley wrote: > > On Wed, 1 Jul 2020 at 18:46, Jeff Davis wrote: > > > > > > On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote: > > >> > > >> Does anyone have any objections to that being change

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-27 Thread David Rowley
On Tue, 28 Jul 2020 at 15:21, Peter Geoghegan wrote: > Separately, I wonder what your opinion is about what should happen for > the partial sort related EXPLAIN ANALYZE format open item, described > here: > > https://www.postgresql.org/message-id/flat/20200619040358.GZ17995%40telsasoft.com#b20bd20

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-27 Thread David Rowley
On Tue, 28 Jul 2020 at 15:01, Justin Pryzby wrote: > > On Tue, Jul 28, 2020 at 12:54:35PM +1200, David Rowley wrote: > > On Mon, 27 Jul 2020 at 14:54, Justin Pryzby wrote: > > > It's unrelated to hashAgg vs hashJoin, but I also noticed that this is > > > shown > > > only conditionally: > > > > >

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-27 Thread Justin Pryzby
On Mon, Jul 27, 2020 at 08:20:45PM -0700, Peter Geoghegan wrote: > On Mon, Jul 27, 2020 at 5:54 PM David Rowley wrote: > > hmm. I'm not sure. I think this should follow the same logic as what > > "Disk Usage" follows, and right now we don't show Disk Usage unless we > > spill. Since we only use pa

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-27 Thread Peter Geoghegan
On Mon, Jul 27, 2020 at 5:54 PM David Rowley wrote: > hmm. I'm not sure. I think this should follow the same logic as what > "Disk Usage" follows, and right now we don't show Disk Usage unless we > spill. Since we only use partitions when spilling, I don't think it > makes sense to show the estima

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-27 Thread Justin Pryzby
On Tue, Jul 28, 2020 at 12:54:35PM +1200, David Rowley wrote: > On Mon, 27 Jul 2020 at 14:54, Justin Pryzby wrote: > > It's unrelated to hashAgg vs hashJoin, but I also noticed that this is shown > > only conditionally: > > > > if (es->format != EXPLAIN_FORMAT_TEXT) > > { > >

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-27 Thread David Rowley
On Mon, 27 Jul 2020 at 14:54, Justin Pryzby wrote: > It's unrelated to hashAgg vs hashJoin, but I also noticed that this is shown > only conditionally: > > if (es->format != EXPLAIN_FORMAT_TEXT) > { > if (es->costs && aggstate->hash_planned_partitions > 0) >

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-26 Thread Justin Pryzby
On Mon, Jul 27, 2020 at 10:48:45AM +1200, David Rowley wrote: > On Wed, 1 Jul 2020 at 18:46, Jeff Davis wrote: > > > > On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote: > >> > >> Does anyone have any objections to that being changed? > > > > That's OK with me. By the way, I'm on vacation and will

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-07-26 Thread David Rowley
On Wed, 1 Jul 2020 at 18:46, Jeff Davis wrote: > > On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote: >> >> Does anyone have any objections to that being changed? > > That's OK with me. By the way, I'm on vacation and will catch up on these > HashAgg threads next week. (Adding Justin as I know h

Re: HashAgg's batching counter starts at 0, but Hash's starts at 1.

2020-06-30 Thread Jeff Davis
On Tue, Jun 30, 2020, 7:04 PM David Rowley wrote: > Does anyone have any objections to that being changed? > That's OK with me. By the way, I'm on vacation and will catch up on these HashAgg threads next week. Regards, Jeff Davis