From: | Daniel Migowski <dmigowski(at)ikoffice(dot)de> |
---|---|
To: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Adding column "mem_usage" to view pg_prepared_statements |
Date: | 2019-07-27 18:29:23 |
Message-ID: | 41ED3F5450C90F4D8381BC4D8DF6BBDCF02E04F2@EXCHANGESERVER.ikoffice.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
I just implemented a small change that adds another column "mem_usage" to the system view "pg_prepared_statements". It returns the memory usage total of CachedPlanSource.context, CachedPlanSource.query_content and if available CachedPlanSource.gplan.context.
Looks like this:
IKOffice_Daume=# prepare test as select * from vw_report_salesinvoice where salesinvoice_id = $1;
PREPARE
IKOffice_Daume=# select * from pg_prepared_statements;
name | statement | prepare_time | parameter_types | from_sql | mem_usage
------+----------------------------------------------------------------------------------+------------------------------+-----------------+----------+-----------
test | prepare test as select * from vw_report_salesinvoice where salesinvoice_id = $1; | 2019-07-27 20:21:12.63093+02 | {integer} | t | 33580232
(1 row)
I did this in preparation of reducing the memory usage of prepared statements and believe that this gives client application an option to investigate which prepared statements should be dropped. Also this makes it possible to directly examine the results of further changes and their effectiveness on reducing the memory load of prepared_statements.
Is a patch welcome or is this feature not of interest?
Also I wonder why the "prepare test as" is part of the statement column. I isn't even part of the real statement that is prepared as far as I would assume. Would prefer to just have the "select *..." in that column.
Kind regards,
Daniel Migowski
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-07-27 18:55:02 | Re: Testing LISTEN/NOTIFY more effectively |
Previous Message | Julien Rouhaud | 2019-07-27 18:23:42 | Re: Add parallelism and glibc dependent only options to reindexdb |