Re: Query is slower with a large proportion of NULLs in several columns

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Monday, December 20, 2021, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It would help if somebody had labeled the units of I/O Time
>> ... but I'm guessing those are microsec vs. the millisec
>> of the other times, because otherwise it's completely wrong.

> Related to my preceding observation, from the explain (buffers) docs:
> “…and the time spent reading and writing data file blocks (in milliseconds)
> if track_io_timing
> <https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-IO-TIMING>
> is enabled.“

Hmm ... the code sure looks like it's supposed to be millisec:

appendStringInfoString(es->str, "I/O Timings:");
if (!INSTR_TIME_IS_ZERO(usage->blk_read_time))
appendStringInfo(es->str, " read=%0.3f",
INSTR_TIME_GET_MILLISEC(usage->blk_read_time));
if (!INSTR_TIME_IS_ZERO(usage->blk_write_time))
appendStringInfo(es->str, " write=%0.3f",
INSTR_TIME_GET_MILLISEC(usage->blk_write_time));

And when I try some cases here, I get I/O timing numbers that are
consistent with the overall time reported by EXPLAIN, for example

Seq Scan on foo (cost=0.00..843334.10 rows=11000010 width=508) (actual time=0.
015..1897.492 rows=11000000 loops=1)
Buffers: shared hit=15874 read=717460
I/O Timings: read=1184.638
Planning:
Buffers: shared hit=5 read=2
I/O Timings: read=0.025
Planning Time: 0.229 ms
Execution Time: 2151.529 ms

So now we have a real mystery about what is happening on Lars'
system. Those numbers can't be right.

regards, tom lane