| From: | Amit Langote <amitlangote09(at)gmail(dot)com> |
|---|---|
| To: | "James Pang (chaolpan)" <chaolpan(at)cisco(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: huge memory of Postgresql backend process |
| Date: | 2022-09-09 08:41:51 |
| Message-ID: | CA+HiwqFUw_s=m86CPHCoABOLtNGXpgfSDTnJwdETaQWHiLq=tw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi,
On Fri, Sep 9, 2022 at 5:19 PM James Pang (chaolpan) <chaolpan(at)cisco(dot)com> wrote:
> Thanks for you suggestion, yes, we reduced partition count from 256 to 128, then to 64. The memory got reduced from 170M to 91MB then to 60M.
> It's from Postgresql JDBC client, preparedStatementCacheQueries=(default 256), reduce that from JDBC parameter can help reduce "cached plan context" ?
Interesting that you mention "cached plan context".
Cached plans for queries over partitioned tables tend to be big (in
terms of memory they take up in the plan cache) because the planner
can't use partition pruning. One workaround might be to forcefully
prevent plan caching by setting plan_cache_mode to
'force_custom_plan', which makes a backend rebuild the plan on every
execution of a prepared statement.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | egashira.yusuke@fujitsu.com | 2022-09-09 12:22:33 | RE: BUG #17611: SJIS conversion rule about duplicated characters differ from Windows |
| Previous Message | James Pang (chaolpan) | 2022-09-09 08:19:33 | RE: huge memory of Postgresql backend process |