Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iRPPl-0006nt-6b for pgsql-docs@arkaria.postgresql.org; Sun, 03 Nov 2019 23:36:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iRPPj-0007l3-Je for pgsql-docs@arkaria.postgresql.org; Sun, 03 Nov 2019 23:36:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iRPPj-0007kw-AL for pgsql-docs@lists.postgresql.org; Sun, 03 Nov 2019 23:36:07 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iRPPg-0005iY-Jl for pgsql-docs@lists.postgresql.org; Sun, 03 Nov 2019 23:36:06 +0000 Received: by mail-wr1-x443.google.com with SMTP id t1so9119244wrv.4 for ; Sun, 03 Nov 2019 15:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EGTT+lGFU3gOQdsPMR+uSHeE882NeX/A9twoGS92NZ0=; b=GXiIo2Et9LEO/2ClHlHF0bF9gGsX4EyLeiv5Nony87iuJqVXABnIsSVjpNn1QfDXz/ 7kdkPOKD9OHM6xWY1J1DZMzl9I5Ryc7FQYMQqVFcehBYzYyTlZdCg/BQd5FaSjB59D/C dAMmXcQS9JnKKWywQgn3HilOyGXJ2M07qQ0Om1JAss5nAMAqjRutQPsk8yT7wNoWqkiH uSwfXU35wcflplR6+wIh8NxHLEsQdrt8URo+W2lfzMfRJMHjdlcLYVYt62bWBXchBj1L ifihoBR/A9tWmiyz0YJKpvcViYUM+G2ZYxdCZjdU8N5zP/8IKo/EOdAYfiLVgnMD8aba Ao1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EGTT+lGFU3gOQdsPMR+uSHeE882NeX/A9twoGS92NZ0=; b=rZpymHU0ZmrnKwC2GcU2xOZlSHgYbZ0nw9vviM+tk4o1mVhgqmY7B/XSy3z4QdnTvi M3U8HrDyOFYKLahuanN8NzHLHpMWYuiwZV5+nAyvpFDEbcOHRsHrWscPPOnU1XqReAgA OTsEbJ9PUnqoq/zl5AC1tcvLq+Q2Coh6GIWhjB6kmuakRtVG7LiDo/z7ft+zpbljUqee S5pupFH2uGo7gosiFLH/XAbgh3cHha7aNsdDHPJmuMfrPYuxbutVNcYjlvDOEzWvZ7pj 4zg7GrZp5n9HLWORAEdCo5RIiCSWAWcbYFPHfBeQ1XWOlxkvZOW8CUGL2WwRrYCdxDc/ XD1A== X-Gm-Message-State: APjAAAV0n4zp2u66HPaeG7B6tYPsfKfK6F/uDEWEbdl4Bh2Q5Tj5jTds xWoxO7txzcfAiRtVIdvWzeQSwDnkUXEZwRikx9nWdGyeZ0w= X-Google-Smtp-Source: APXvYqxiSpCltMw+mVFgOencAqK1UrLuSmbcPnwPcC+1k1fB03W2eITyDwnZCTezpjYtacUCcSJbThtbWnhJUTyd2us= X-Received: by 2002:a5d:6b0a:: with SMTP id v10mr19341689wrw.32.1572824162986; Sun, 03 Nov 2019 15:36:02 -0800 (PST) MIME-Version: 1.0 References: <20181105161231.GA13780@momjian.us> <20181105170112.dtxazkxcyuoszfi2@alvherre.pgsql> <20181106184220.GA31546@momjian.us> In-Reply-To: <20181106184220.GA31546@momjian.us> From: Nikolay Samokhvalov Date: Mon, 4 Nov 2019 02:35:51 +0300 Message-ID: Subject: Re: effective_cache_size To: Bruce Momjian Cc: Alvaro Herrera , nat@makarevitch.org, peter.eisentraut@2ndquadrant.com, pgsql-docs@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000877170059679a9fc" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000877170059679a9fc Content-Type: text/plain; charset="UTF-8" A follow-up on this: Should documentation also mention that it does not make sense to set effective_cache_size < shared_buffers? And maybe it is worth prohibiting this or at least having a WARNING in logs? Why: I see setups where with growing RAM and shared_buffers set to 25%, effective_cache_size remains untuned, at some point significantly below the value of shared_buffers. On Tue, Nov 6, 2018 at 21:42 Bruce Momjian wrote: > On Mon, Nov 5, 2018 at 02:01:12PM -0300, Alvaro Herrera wrote: > > On 2018-Nov-05, Bruce Momjian wrote: > > > > > Well, here are the lines in guc.c: > > > > > > gettext_noop("Sets the planner's assumption about the size > of the data cache."), > > > gettext_noop("That is, the size of the cache used for > PostgreSQL data files. " > > > "This is measured in disk pages, which are > normally 8 kB each."), > > > > I suggest "the size of data caches", plural, in the first line (two > > letters shorter, since I lost the article). And in the second line, use > > "... the size of the combined caches used for Pg data files, including > > both the kernel cache and shared buffers" -- a few words longer, which > > seems worth it to me. > > OK, I handled it slightly differently: > > > https://git.postgresql.org/pg/commitdiff/b43df566b372650a9b9e2a0dd9e695c1f16da14f > > I think "the size of" anything plural is confusing so I said "the total > size of". > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + As you are, so once was I. As I am, so you will be. + > + Ancient Roman grave inscription + > --000000000000877170059679a9fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A follow-up on this:
Should documentation also mention that it does no= t make sense to set effective_cache_size < shared_buffers? And maybe it = is worth prohibiting this or at least having a WARNING in logs?

Why: I see setups where with growin= g RAM and shared_buffers set to 25%, effective_cache_size remains untuned, = at some point significantly below the value of shared_buffers.
On Tue, = Nov 6, 2018 at 21:42 Bruce Momjian <= bruce@momjian.us> wrote:
On = Mon, Nov=C2=A0 5, 2018 at 02:01:12PM -0300, Alvaro Herrera wrote:
> On 2018-Nov-05, Bruce Momjian wrote:
>
> > Well, here are the lines in guc.c:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gettext_noop("= ;Sets the planner's assumption about the size of the data cache.")= ,
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gettext_noop("= ;That is, the size of the cache used for PostgreSQL data files. "
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 "This is measured in disk pages, which are no= rmally 8 kB each."),
>
> I suggest "the size of data caches", plural, in the first li= ne (two
> letters shorter, since I lost the article).=C2=A0 And in the second li= ne, use
> "... the size of the combined caches used for Pg data files, incl= uding
> both the kernel cache and shared buffers" -- a few words longer, = which
> seems worth it to me.

OK, I handled it slightly differently:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://git.postgresql.org/pg/commitdiff/b43df566b372650a9b9e2a0dd= 9e695c1f16da14f

I think "the size of" anything plural is confusing so I said &quo= t;the total
size of".

--
=C2=A0 Bruce Momjian=C2=A0 <bruce@momjian.us>=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://momjian.us
=C2=A0 EnterpriseDB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
http://enterprisedb.com
+ As you are, so once was I.=C2=A0 As I am, so you will be. +
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Ancient Roman grave inscription +
--000000000000877170059679a9fc--