On Thu, Jun 25, 2020 at 12:33 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > On Thu, Jun 25, 2020 at 8:42 AM James Coleman <jtc...@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
