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

From Robert Haas
Subject Re: Creating a function for exposing memory usage of backend process
Date
Msg-id CA+TgmobkpFV0UB67kzXuD36--OFHwz1bs=L_6PZbD4nxKqUQMw@mail.gmail.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  (torikoshia <torikoshia@oss.nttdata.com>)
List pgsql-hackers
On Wed, Jun 17, 2020 at 11:56 PM Fujii Masao
<masao.fujii@oss.nttdata.com> wrote:
> > As a first step, to deal with (3) I'd like to add
> > pg_stat_get_backend_memory_context() which target is limited to the
> > local backend process.
>
> +1

+1 from me, too. Something that exposed this via shared memory would
be quite useful, and there are other things we'd like to expose
similarly, such as the plan(s) from the running queries, or even just
the untruncated query string(s). I'd like to have a good
infrastructure for that sort of thing, but I think it's quite tricky
to do properly. You need a variable-size chunk of shared memory, so
probably it has to use DSM somehow, and you need to update it as
things change, but if you update it too frequently performance will
stink. If you ping processes to do the updates, how do you know when
they've completed them, and what happens if they don't respond in a
timely fashion? These are probably all solvable problems, but I don't
think they are very easy ones.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: compile cube extension with float4 precision storing
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] Allow to specify restart_lsn inpg_create_physical_replication_slot()