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

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Creating a function for exposing memory usage of backend process
Date: 2020-07-03 02:45:52
Message-ID: 805313b5f7dc2e6c19b209ff930a7a61@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 1, 2020 at 10:15 PM torikoshia <torikoshia(at)oss(dot)nttdata(dot)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(dot)fujii(at)oss(dot)nttdata(dot)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 Content-Type Size
0003-Adding-a-function-exposing-memory-usage-of-local-backend.patch text/x-diff 12.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-07-03 02:46:49 Re: Default setting for enable_hashagg_disk (hash_mem)
Previous Message Peter Geoghegan 2020-07-03 02:43:46 Re: track_planning causing performance regression