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

Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>

From: Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, torikoshia <torikoshia@oss.nttdata.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2020-06-26T08:43:49Z
Lists: pgsql-hackers
Hi,

On Fri, Jun 26, 2020 at 3:42 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> While going through the mail chain on relation, plan and catalogue
> caching [1], I'm thinking on the lines that is there a way to know the
> current relation, plan and catalogue cache sizes? If there is a way
> already,  please ignore this and it would be grateful if someone point
> me to that.
AFAIK the only way to get statistics on PostgreSQL's backend  internal
local memory usage is to use MemoryContextStats() via gdb to output
the information to the log, so far.

> If there is no such way to know the cache sizes and other info such as
> statistics, number of entries, cache misses, hits etc.  can the
> approach discussed here be applied?
I think it's partially yes.

> If the user knows the cache statistics and other information, may be
> we can allow user to take appropriate actions such as allowing him to
> delete few entries through a command or some other way.
Yeah, one of the purposes of the features we are discussing here is to
use them for such situation.

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.