Re: Creating a function for exposing memory usage of backend process - Mailing list pgsql-hackers

From torikoshia
Subject Re: Creating a function for exposing memory usage of backend process
Date
Msg-id 805313b5f7dc2e6c19b209ff930a7a61@oss.nttdata.com
Whole thread Raw
In response to Re: Creating a function for exposing memory usage of backend process  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Creating a function for exposing memory usage of backend process
List pgsql-hackers
On Wed, Jul 1, 2020 at 10:15 PM torikoshia <torikoshia@oss.nttdata.com> 
wrote:
> I'm going to do some renaming and transportations.
> 
> - view name: pg_memory_contexts
> - function name: pg_get_memory_contexts()
> - source file: mainly src/backend/utils/mmgr/mcxt.c

Attached an updated patch.

On Wed, Jul 1, 2020 at 10:58 PM Fujii Masao 
<masao.fujii@oss.nttdata.com> wrote:
> Ok, understood! I agree that it's strange to display different names
> for the same memory context between this view and logging.
> 
> It's helpful if the comment there refers to MemoryContextStatsPrint()
> and mentions the reason that you told.

Agreed. I changed the comments.

> > It also derived from MemoryContextStatsPrint().
> > I suppose it is for keeping readability of the log..
> 
> Understood. I may want to change the upper limit of query size to 
> display.
> But at the first step, I'm fine with limitting 1024 bytes.

Thanks, I've left it as it was.

> > I'm going to follow the discussion on the mailing list and find why
> > these codes were introduced.
> 
> https://www.postgresql.org/message-id/12319.1521999065%40sss.pgh.pa.us

Thanks for sharing!


Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION
Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: track_planning causing performance regression
Next
From: Fujii Masao
Date:
Subject: Re: track_planning causing performance regression