Re: Add tracking of backend memory allocated to pg_stat_activity

Greetings,

* Drouvot, Bertrand (bdrouvot(at)amazon(dot)com) wrote:
> On 9/1/22 3:28 AM, Kyotaro Horiguchi wrote:
> >At Wed, 31 Aug 2022 12:05:55 -0500, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote in
> >>On Wed, Aug 31, 2022 at 12:03:06PM -0400, Reid Thompson wrote:
> >>>Attached is a patch to
> >>>Add tracking of backend memory allocated
>
> Thanks for the patch.
>
> + 1 on the idea.

Glad folks are in support of the general idea.

> >>>+ proargmodes => '{i,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o,o}',
> >>In the past, there was concern about making pg_stat_activity wider by
> >>adding information that's less-essential than what's been there for
> >>years. This is only an int64, so it's not "wide", but I wonder if
> >>there's another way to expose this information? Like adding backends to
> >The view looks already too wide to me. I don't want the numbers for
> >metrics are added to the view.
>
> +1 for a dedicated view.

A dedicated view with a single column in it hardly seems sensible. I'd
also argue that this particular bit of information is extremely useful
and therefore worthy of being put directly into pg_stat_activity. I
could see a dedicated view possibly *also* being added later if/when we
provide a more detailed break-down of how the memory is being used but
that's a whole other thing and I'm not even 100% sure we'll ever
actually get there, as you can already poke a backend and have it dump
out the memory context-level information on an as-needed basis.

> While we are at it, what do you think about also recording the max memory
> allocated by a backend? (could be useful and would avoid sampling for which
> there is no guarantee to sample the max anyway).

What would you do with that information..? By itself, it doesn't strike
me as useful. Perhaps it'd be interesting to grab the max required for
a particular query in pg_stat_statements or such but again, that's a
very different thing.

Thanks,

Stephen