pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: torikoshia <torikoshia@oss.nttdata.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Creating a function for exposing memory usage of backend process
Date: Fri, 10 Jul 2020 17:30:22 +0900
Message-ID: <7ced23175178d54c9be05f985d1a9f94@oss.nttdata.com> (raw)
In-Reply-To: <ba63f735-d75e-28b5-ab13-a888ab5c2301@oss.nttdata.com>
References: <72a656e0f71d0860161e0b3f67e4d771@oss.nttdata.com>
	<398eb7cd-5f75-be1c-3897-36865b7bfabf@oss.nttdata.com>
	<CA+TgmobkpFV0UB67kzXuD36--OFHwz1bs=L_6PZbD4nxKqUQMw@mail.gmail.com>
	<3193c7d590f3212e543b63df977da758@oss.nttdata.com>
	<78268b5f-53ed-4645-1abb-23c1030cce0a@oss.nttdata.com>
	<6c828f3a1d44dba81999fc7990b8f1c5@oss.nttdata.com>
	<e068e42d-8eda-fbe5-e84c-7188e9386778@oss.nttdata.com>
	<062bab2db5645812fae12e3a965de463@oss.nttdata.com>
	<5cbed0cc-79fc-3b98-120a-20e07848d10a@oss.nttdata.com>
	<805313b5f7dc2e6c19b209ff930a7a61@oss.nttdata.com>
	<a9d68488-8343-5d70-4612-311d597f9962@oss.nttdata.com>
	<cd0e961fd42e5708fdea70f7420bf214@oss.nttdata.com>
	<9ee242b1-9e70-18f5-0033-6a086e71164d@oss.nttdata.com>
	<3548926512ddfaedfb5eaf967bf2f196@oss.nttdata.com>
	<ba63f735-d75e-28b5-ab13-a888ab5c2301@oss.nttdata.com>

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






view thread (57+ messages)  latest in thread

Message-ID: <7ced23175178d54c9be05f985d1a9f94@oss.nttdata.com>
Permalink:  ../7ced23175178d54c9be05f985d1a9f94@oss.nttdata.com/
Also on:    postgresql.org/message-id/7ced23175178d54c9be05f985d1a9f94@oss.nttdata.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: torikoshia@oss.nttdata.com, masao.fujii@oss.nttdata.com
  Subject: Re: Creating a function for exposing memory usage of backend process
  In-Reply-To: <7ced23175178d54c9be05f985d1a9f94@oss.nttdata.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox