On Thu, Jun 25, 2020 at 12:33 PM 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.
Do we print zeroes for memory usage when all sorts ended up spilling
to disk then? That might be the current behavior; I'd have to check.
Because that's a lie, but we don't have any better information
currently (which is unfortunate, but hardly in scope for fixing here.)
James
