Re: Add tracking of backend memory allocated to pg_stat_activity
От | Drouvot, Bertrand |
---|---|
Тема | Re: Add tracking of backend memory allocated to pg_stat_activity |
Дата | |
Msg-id | 4c6b042a-f79c-29c0-8ce6-f3b13613dcab@amazon.com обсуждение исходный текст |
Ответ на | Re: Add tracking of backend memory allocated to pg_stat_activity (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Add tracking of backend memory allocated to pg_stat_activity
|
Список | pgsql-hackers |
Hi, On 9/1/22 3:28 AM, Kyotaro Horiguchi wrote: > At Wed, 31 Aug 2022 12:05:55 -0500, Justin Pryzby <pryzby@telsasoft.com> wrote in >> On Wed, Aug 31, 2022 at 12:03:06PM -0400, Reid Thompson wrote: >>> Hi Hackers, >>> >>> Attached is a patch to >>> Add tracking of backend memory allocated Thanks for the patch. + 1 on the 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. 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). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: