Re: Adding column "mem_usage" to view pg_prepared_statements - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Adding column "mem_usage" to view pg_prepared_statements
Date
Msg-id 62f9a873-e214-6044-37b3-9b6f3476d631@postgrespro.ru
Whole thread Raw
In response to Re: Adding column "mem_usage" to view pg_prepared_statements  (Daniel Migowski <dmigowski@ikoffice.de>)
Responses Re: Adding column "mem_usage" to view pg_prepared_statements  (Daniel Migowski <dmigowski@ikoffice.de>)
List pgsql-hackers

On 31.07.2019 1:38, Daniel Migowski wrote:
>
> Am 31.07.2019 um 00:29 schrieb Tom Lane:
>> Daniel Migowski <dmigowski@ikoffice.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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions