Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jtoQQ-0004Xj-1d
	for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2020 08:30:30 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1jtoQO-0003ME-VM
	for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2020 08:30:28 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <torikoshia@oss.nttdata.com>)
	id 1jtoQO-0003M0-Ob
	for pgsql-hackers@lists.postgresql.org; Fri, 10 Jul 2020 08:30:28 +0000
Received: from oss.nttdata.com ([49.212.34.109])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <torikoshia@oss.nttdata.com>)
	id 1jtoQM-0005CJ-99
	for pgsql-hackers@postgresql.org; Fri, 10 Jul 2020 08:30:27 +0000
Received: from oss.nttdata.com (localhost [127.0.0.1])
	by oss.nttdata.com (Postfix) with ESMTP id 080926020F;
	Fri, 10 Jul 2020 17:30:22 +0900 (JST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 10 Jul 2020 17:30:22 +0900
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
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>
Message-ID: <7ced23175178d54c9be05f985d1a9f94@oss.nttdata.com>
X-Sender: torikoshia@oss.nttdata.com
User-Agent: Roundcube Webmail/1.1.9
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

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