On Fri, 26 Jun 2020 at 04:33, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Thu, Jun 25, 2020 at 8:42 AM James Coleman <jtc331@gmail.com> wrote:
> >> Yesterday I'd replied [1] to Justin's proposal for this WRT
> >> incremental sort and expressed my opinion that including both
> >> unnecessarily (i.e., including disk when an in-memory sort was used)
> >> is undesirable and confusing and leads to shortcuts I believe to be
> >> bad habits when using the data programmatically.
>
> > +1.
>
> I think the policy about non-text output formats is "all applicable
> fields should be included automatically". But the key word there is
> "applicable". Are disk-sort numbers applicable when no disk sort
> happened?
>
> I think the right way to think about this is that we are building
> an output data structure according to a schema that should be fixed
> for any particular plan shape. If event X happened zero times in
> a given execution, but it could have happened in a different execution
> of the same plan, then we should print X with a zero count. If X
> could not happen period in this plan, we should omit X's entry.
>
> So the real question here is whether the disk vs memory decision is
> plan time vs run time. AFAIK it's run time, which leads me to think
> we ought to print the zeroes.
I think that's a pretty good way of thinking about it.
For the HashAgg case, the plan could end up spilling, so based on what
you've said, we should be printing those zeros as some other execution
of the same plan could spill.
If nobody objects to that very soon, then I'll go ahead and push the
changes for HashAgg's non-text EXPLAIN ANALYZE
David