Re: Adding column "mem_usage" to view pg_prepared_statements

Поиск
Список
Период
Сортировка
От Konstantin Knizhnik
Тема Re: Adding column "mem_usage" to view pg_prepared_statements
Дата
Msg-id 62f9a873-e214-6044-37b3-9b6f3476d631@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Adding column "mem_usage" to view pg_prepared_statements  (Daniel Migowski <dmigowski@ikoffice.de>)
Ответы Re: Adding column "mem_usage" to view pg_prepared_statements  (Daniel Migowski <dmigowski@ikoffice.de>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions