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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Query is slower with a large proportion of NULLs in several columns
Дата
Msg-id 2707817.1640064786@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Query is slower with a large proportion of NULLs in several columns  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-performance
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Monday, December 20, 2021, Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-performance по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Query is slower with a large proportion of NULLs in several columns
Следующее
От: Marc Millas
Дата:
Сообщение: 9.6 write time