Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements

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

In response to

Responses

Browse pgsql-hackers by date

  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)