Re: Creating a function for exposing memory usage of backend process

On 2020-07-08 22:12, Fujii Masao wrote:
> Thanks for updating the patch! It basically looks good to me.
> 
> +  <indexterm zone="view-pg-backend-memory-contexts">
> +   <primary>backend memory contexts</primary>
> +  </indexterm>
> 
> Do we need this indexterm?

Thanks! it's not necessary. I remove this indexterm.


>>> 
>>> +{ oid => '2282', descr => 'statistics: information about all memory
>>> contexts of local backend',
>>> 
>>> Isn't it better to remove "statistics: " from the above description?
>> 
>> Yeah, it's my oversight.
>> 
>>> 
>>> +     <row>
>>> +      <entry role="catalog_table_entry"><para 
>>> role="column_definition">
>>> +       <structfield>parent</structfield> <type>text</type>
>>> 
>>> There can be multiple memory contexts with the same name. So I'm 
>>> afraid
>>> that it's difficult to identify the actual parent memory context from 
>>> this
>>> "parent" column. This is ok when logging memory contexts by calling
>>> MemoryContextStats() via gdb. Because child memory contexts are 
>>> printed
>>> just under their parent, with indents. But this doesn't work in the 
>>> view.
>>> To identify the actual parent memory or calculate the memory contexts 
>>> tree
>>> from the view, we might need to assign unique ID to each memory 
>>> context
>>> and display it. But IMO this is overkill. So I'm fine with current 
>>> "parent"
>>> column. Thought? Do you have any better idea?
>> 
>> Indeed.
>> I also feel it's not usual to assign a unique ID, which
>> can vary every time the view displayed.
> 
> Agreed. Displaying such ID would be more confusing to users.
> Ok, let's leave the code as it is.
> 
> Another comment about parent column is: dynahash can be parent?
> If yes, its indent instead of name should be displayed in parent 
> column?

I'm not sure yet, but considering the changes in the future, it seems
better to do so.

But if we add information for identifying parent-child relation like the
memory address suggested from Andres, it seems not necessary.

So I'd like to go back to this point.



Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION