From: | "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, <reid(dot)thompson(at)crunchydata(dot)com>, <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add tracking of backend memory allocated to pg_stat_activity |
Date: | 2022-09-12 07:59:15 |
Message-ID: | 9a3ac0ad-0f35-d0ee-652d-09bf5af1c3ba@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 9/9/22 7:08 PM, Justin Pryzby wrote:
> On Fri, Sep 09, 2022 at 12:34:15PM -0400, Stephen Frost wrote:
>>> 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.
>
> Storing the maxrss per backend somewhere would be useful (and avoid the
> issue of "sampling" with top), after I agree that it ought to be exposed
> to a view. For example, it might help to determine whether (and which!)
> backends are using large multiple of work_mem, and then whether that can
> be increased. If/when we had a "memory budget allocator", this would
> help to determine how to set its GUCs, maybe to see "which backends are
> using the work_mem that are precluding this other backend from using
> efficient query plan".
+1.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services:https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Shinya Kato | 2022-09-12 08:03:25 | Re: [PATCH]Feature improvement for MERGE tab completion |
Previous Message | Daniel Gustafsson | 2022-09-12 07:58:37 | Re: proposal: possibility to read dumped table's name from file |