Horton

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

Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>

View thread View on postgr.es
From: Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>
To: torikoshia <torikoshia@oss.nttdata.com>
Cc: Andres Freund <andres@anarazel.de>, Fujii Masao <masao.fujii@oss.nttdata.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-07-30T06:13:51Z
Lists: pgsql-hackers 
Hi,

On Fri, Jul 10, 2020 at 5:32 PM torikoshia <torikoshia@oss.nttdata.com> wrote:
> - whether information for identifying parent-child relation is necessary
> or it's an overkill
I think it's important to understand the parent-child relationship of
the context.
Personally, I often want to know the following two things ..

- In which life cycle is the target context? (Remaining as long as the
process is living? per query?)
- Does the target context belong to the correct (parent) context?

> - if this information is necessary, memory address is suitable or other
> means like assigning unique numbers are required
IMO, If each context can be uniquely identified (or easily guessed) by
"name" and "ident",
then I don't think the address information is necessary.
Instead, I like the way that directly shows the context name of the
parent, as in the 0005 patch.

Best regards

-- 
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com

Commits

  1. Add regression test for pg_backend_memory_contexts.

  2. Move codes for pg_backend_memory_contexts from mmgr/mcxt.c to adt/mcxtfuncs.c.

  3. Prevent non-superusers from reading pg_backend_memory_contexts, by default.

  4. Add pg_backend_memory_contexts system view.

  5. Fix yet another issue with step generation in partition pruning.