Hello,
At Sun, 18 Aug 2019 09:43:09 +0200, Daniel Migowski <dmigowski@ikoffice.de> wrote in
<6e25ca12-9484-8994-a1ee-40fdbe6afa8b@ikoffice.de>
> Am 17.08.2019 um 19:10 schrieb Ibrar Ahmed:
> > On Sat, Aug 17, 2019 at 6:58 PM Daniel Migowski <dmigowski@ikoffice.de
> > <mailto:dmigowski@ikoffice.de>> wrote:
> >
> >
> > attached you find a patch that adds a new GUC:
> >
> >
> > Quick questions before looking at the patch.
> >
> >
> > prepared_statement_limit:
> >
> > - Do we have a consensus about the name of GUC? I don't think it is
> > the right name for that.
The almost same was proposed [1] as a part of syscache-pruning
patch [2], but removed to concentrate on defining how to do that
on the first instance - syscache. We have some mechanisms that
have the same characteristics - can be bloat and no means to keep
it in a certain size. It is better that they are treated the same
way, or at leaast on the same principle.
[1] https://www.postgresql.org/message-id/20180315.141246.130742928.horiguchi.kyotaro%40lab.ntt.co.jp
[2] https://commitfest.postgresql.org/23/931/
Pruning plancaches in any means is valuable, but we haven't
reached a concsensus on how to do that. My old patch does that
based on the number of entries because precise memory accounting
of memory contexts is too expensive. I didn't look this patch
closer but it seems to use MemoryContext->methods->stats to count
memory usage, which would be too expensive for the purpose. We
currently use it only for debug output on critical errors like
OOM.
> No, it is a proposal. It could also be named plancache_mem or
> cachedplansource_maxmem or anything else. It was intended to make
> prepared statements not use up all my mem, but development has shown
> that it could also be used for other CachedPlans, as long as it is a
> saved plan.
> > - Is this a WIP patch or the final patch? Because I can see TODO and
> > non-standard
> > comments in the patch.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center