Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written}
От | hubert depesz lubaczewski |
---|---|
Тема | Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written} |
Дата | |
Msg-id | ZUEK9+J55o6Fhoxl@depesz.com обсуждение исходный текст |
Ответ на | Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written} (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pgBufferUsage.blk_{read|write}_time are zero although there are pgBufferUsage.local_blks_{read|written}
|
Список | pgsql-hackers |
On Tue, Oct 31, 2023 at 08:17:52AM +0900, Michael Paquier wrote: > Thanks for the input. I was looking yesterday if this code was > available somewhere, but couldn't find it.. Until this morning: > https://gitlab.com/depesz/explain.depesz.com.git Well, the parser itself is https://gitlab.com/depesz/Pg--Explain/ :) > And.. It looks like things would become better if we change > "shared/local" to "shared", because the parsing code seems to have an > issue once you add a '/'. All the fields in I/O Timings are > considered as part of a Node, and they're just included in the output. > Now, pasting a plan that includes "shared/local" drops entirely the > string from the output result, so some information is lost. In short, > imagine that we have the following string in a node: > I/O Timings: shared/local write=23.77 > > This would show up like that, meaning that the context where the > write/read timings happened is lost: > I/O Timings: write=23.77 > > If we switch back to "shared", the context would be kept around. Of > course, this does not count for all the parsers that may be out > there, but at least that's something. Well, if it's possible to deduce what is the meaning in given line, I can add the logic to do the deduction to parser. Also, I want to say that I appreciate being looped in the discussion. Best regards, depesz
В списке pgsql-hackers по дате отправления: