Re: Adding column "mem_usage" to view pg_prepared_statements

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: Daniel Migowski <dmigowski(at)ikoffice(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding column "mem_usage" to view pg_prepared_statements
Date: 2019-08-05 16:30:08
Message-ID: 62f9a873-e214-6044-37b3-9b6f3476d631@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31.07.2019 1:38, Daniel Migowski wrote:
>
> Am 31.07.2019 um 00:29 schrieb Tom Lane:
>> Daniel Migowski <dmigowski(at)ikoffice(dot)de> writes:
>>> Ok, just have read about the commitfest thing. Is the patch OK for
>>> that? Or is there generally no love for a mem_usage column here? If
>>> it was, I really would add some memory monitoring in our app
>>> regarding this.
>> You should certainly put it into the next commitfest.  We might or
>> might not accept it, but if it's not listed in the CF we might
>> not remember to even review it.  (The CF app is really a to-do
>> list for patches ...)
>
> OK, added it there. Thanks for your patience :).
>
> Regards,
> Daniel Migowski
>

The patch is not applied to the most recent source because extra
parameter was added to CreateTemplateTupleDesc method.
Please rebase it - the fix is trivial.

I think that including in pg_prepared_statements information about
memory used this statement is very useful.
CachedPlanMemoryUsage function may be useful not only for this view, but
for example it is also need in my autoprepare patch.

I wonder if you consider go further and not only report but control
memory used by prepared statements?
For example implement some LRU replacement discipline on top of prepared
statements cache which can
evict rarely used prepared statements to avoid memory overflow.
We have such patch for PgPro-EE but it limits only number of prepared
statement, not taken in account amount of memory used by them.
I think that memory based limit will be more accurate (although it adds
more overhead).

If you want, I can be reviewer of your patch.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-08-05 16:31:00 Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Previous Message Tom Lane 2019-08-05 16:25:05 Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions