Thread: EXPLAIN vs track_io_timing=on vs tests

Hi

I run my development instances with track_io_timing=on, as I've found
that to be really useful. Unfortunately that causes tests to fail
whenever I forget to turn that off to run installcheck.

The diffs are caused by the additional data shown in the explain tests:
...
-       "Temp Written Blocks": N    +
+       "Temp Written Blocks": N,   +
+       "I/O Read Time": N.N,       +
+       "I/O Write Time": N.N       +
...


First, why is the output of these fields conditional when using a
non-text format?  Seems we instead should output -1 or null. The latter
seems a bit clearer, but is a bit json specific. I guess we could add a
ExplainPropertyNull() or such?

Second, as long as it is conditional, would anybody mind if I put a
track_io_timing=false into explain.sql? We don't try to make the tests
pass with every possible option set, but track_io_timing seems common
enough?

Greetings,

Andres Freund

Hi,

On 2020-10-29 16:10:37 -0700, Andres Freund wrote:
> I run my development instances with track_io_timing=on, as I've found
> that to be really useful. Unfortunately that causes tests to fail
> whenever I forget to turn that off to run installcheck.
> 
> The diffs are caused by the additional data shown in the explain tests:
> ...
> -       "Temp Written Blocks": N    +
> +       "Temp Written Blocks": N,   +
> +       "I/O Read Time": N.N,       +
> +       "I/O Write Time": N.N       +
> ...
> 
> 
> First, why is the output of these fields conditional when using a
> non-text format?  Seems we instead should output -1 or null. The latter
> seems a bit clearer, but is a bit json specific. I guess we could add a
> ExplainPropertyNull() or such?

Not addressed so far.


> Second, as long as it is conditional, would anybody mind if I put a
> track_io_timing=false into explain.sql? We don't try to make the tests
> pass with every possible option set, but track_io_timing seems common
> enough?

Done that now.

Greetings,

Andres Freund