From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | dmigowski(at)ikoffice(dot)de |
Cc: | ibrar(dot)ahmad(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, k(dot)knizhnik(at)postgrespro(dot)ru |
Subject: | Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements |
Date: | 2019-08-19 03:57:22 |
Message-ID: | 20190819.125722.02921196.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
At Sun, 18 Aug 2019 09:43:09 +0200, Daniel Migowski <dmigowski(at)ikoffice(dot)de> wrote in <6e25ca12-9484-8994-a1ee-40fdbe6afa8b(at)ikoffice(dot)de>
> Am 17.08.2019 um 19:10 schrieb Ibrar Ahmed:
> > On Sat, Aug 17, 2019 at 6:58 PM Daniel Migowski <dmigowski(at)ikoffice(dot)de
> > <mailto:dmigowski(at)ikoffice(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Lakhin | 2019-08-19 04:04:04 | Fix typos and inconsistencies for HEAD (take 11) |
Previous Message | Smith, Peter | 2019-08-19 02:28:34 | RE: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |