Re: [PG13] Planning (time + buffers) data structure in explain plan (format text) - Mailing list pgsql-hackers

From Pierre Giraud
Subject Re: [PG13] Planning (time + buffers) data structure in explain plan (format text)
Date
Msg-id 4b722826-c897-c057-9795-a87390cce438@dalibo.com
Whole thread Raw
In response to Re: [PG13] Planning (time + buffers) data structure in explain plan (format text)  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: [PG13] Planning (time + buffers) data structure in explain plan (format text)
List pgsql-hackers

Le 07/08/2020 à 14:52, Julien Rouhaud a écrit :
> Hi,
> 
> On Fri, Aug 7, 2020 at 2:30 PM Pierre Giraud <pierre.giraud@dalibo.com> wrote:
>>
>> Hi all,
>>
>> As far as I understand, in the upcoming version 13, information about
>> buffers used during planning is now available in the explain plan.
> 
> Indeed.
> 
>> […]
>>  Planning Time: 0.203 ms
>>    Buffers: shared hit=14
>> […]
>>
>> In the JSON format, the data structure is a bit different:
>>
>> […]
>>      "Planning": {
>>        "Planning Time": 0.533,
>>        "Shared Hit Blocks": 14,
>>        "Shared Read Blocks": 0,
>>        "Shared Dirtied Blocks": 0,
>>        "Shared Written Blocks": 0,
>>        "Local Hit Blocks": 0,
>>        "Local Read Blocks": 0,
>>        "Local Dirtied Blocks": 0,
>>        "Local Written Blocks": 0,
>>        "Temp Read Blocks": 0,
>>        "Temp Written Blocks": 0
>>      },
>> […]
>>
>> For a matter of consistency, I wonder if it would be possible to format
>> it like the following:
>>
>> […]
>>  Planning:
>>    Planning Time: 0.203 ms
>>    Buffers: shared hit=14
>> […]
> 
> I agree that this output looks more consistent with other output,
> including JIT as you mentioned.  I'll send a patch for that if there's
> no objection.

Thanks a lot!

> 
> Out of curiosity, is the current text output actually harder to parse
> than the one you're suggesting?
> 

I don't want to speak in the name of developers of others parsing tools
but this should not require a lot of work to parse the output I'm proposing.
It would be nice to have their opinion though, especially Hubert depesz
Lubaczewski's since he already integrated the change:
https://gitlab.com/depesz/Pg--Explain/-/commit/4a760136ee69ee4929625d4e4022f79ac60b763f

However, as far as I know, he's not doing anything with the buffers
information with the "Planning" section yet.

To answer your question, I think that the new output would make the
parser a little bit easier to write because it would make things a bit
clearer (ie. more separated) so less prone to errors.



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Yet another issue with step generation in partition pruning
Next
From: Robert Haas
Date:
Subject: Re: Parallel worker hangs while handling errors.