Hello, At Sun, 18 Aug 2019 09:43:09 +0200, Daniel Migowski <dmigow...@ikoffice.de> wrote in <6e25ca12-9484-8994-a1ee-40fdbe6af...@ikoffice.de> > Am 17.08.2019 um 19:10 schrieb Ibrar Ahmed: > > On Sat, Aug 17, 2019 at 6:58 PM Daniel Migowski <dmigow...@ikoffice.de > > <mailto:dmigow...@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
