Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5ken-0008Fe-Df for pgsql-performance@arkaria.postgresql.org; Fri, 28 Sep 2018 04:45:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g5kei-0006IG-PN for pgsql-performance@arkaria.postgresql.org; Fri, 28 Sep 2018 04:45:32 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5kei-0006I8-8W for pgsql-performance@lists.postgresql.org; Fri, 28 Sep 2018 04:45:32 +0000 Received: from sonic307-4.consmr.mail.bf2.yahoo.com ([74.6.134.43]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5kee-0003Sk-Ts for pgsql-performance@lists.postgresql.org; Fri, 28 Sep 2018 04:45:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1538109927; bh=y1JPVbkpa9uOoUcXAQGLye3GR1mYZEWoWjtVrF1lmJQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=UPtPTP+RaycQXBaB7y8X4vfO8oQTNtAA/uGxby93CctwOcAPre/NrNAE5BwcDP0Mj5dR84b8Eahcs8pW5zM+b2j76lC76Hl/A94Vz9FHNDFL5HZHtatbD/hjNwCAaDdv4WvoPBBM8J1fotYSSyQ0yfBiSdtJ42I5ghctoXKT2CWJt7tO4NWryxStoVeeslBdH+GB+wosOTVibw6U/bQuI59MjsgShrlQ5R5cueW5To08FcQQb+JZ94+mcSpApi2pewKzZN2Vo9BL6mF7RmNtJIWkRMvusFvjgkG/r7DulaoN7Z6bkjDHbSkh9T8YslN4kR9H0cXPJJlCgLU69wfP/Q== X-YMail-OSG: V_N2pj4VM1mXAve5_nU9RWiEnmLaj7UfvJP6pdYLUSgG6IILeCEoqUEnVzx1Ape LW3sT1XhLw3jtlcQR4MdUK60wv2suItDDmU2aDwqpAOOkTNu3RkXWzyZN1YAwfi90W4oBh30Y.rH STvdlFVsqodpy3Xgu.QhmjJizv3kHWCIRNLdUihv_Tk3f6P6kLfAcUSPLshsgqOuv4lnlVGvc8t. ra3Y.iZsIK1sUYUsyq6qp3zHkIssPR9eAvDSlrSYXIbsNb64NE4R7iUbwIcW_Qdlt55qQk.waweq AZryr_5io3LCo4htvou4gyt64pT9izeAilzEZNyD51.L9uwMFzj_NsmTGG7lzHD60wPZDEx2URKk mJ79ZSAinAJjcjdd88EleaFBv0fGxO1sBlXoyiRgkE9ObJH3VZqrQx4tZs.lnJIW_Hm80e24Kh93 GS16LwTaJeBukfZKla.jJiCEEIy7q04.jsh5OiHiSyrR_Fk2dj0P677h2nM0ydfDSoEg_1baFsDX t98qhC8I7fCdAseHHocJXizD1WBRg.SrXbB7GrlZygW7KX4JMFEuram0A59fYzwx0NbtTfuIwixs hktXIKKrm9753X0v_XyPjtzC7ruozk8vZBRLoGPwY_iaL6MnO72DJnwYUtdpo9kVyoq_ZvMxfPdZ TXYBoyAz4F.pKZJksIrAsT8xGQFhZDVkGDI3fB0_wFLE7VmV_XDXpokXllJM1.xU.xJotNX1f4qD FQf_jwQADdL_99Z2cuByJmH6PCJbROjf7HQrm00rQCD3OSxK0J9jyu3eA5RDvyCwaE4dCW3drvJ_ oYNtWrOjmNL_x2hqlU_feeem8VbYsG6AeVDFav3NB8WAnaShfTqvBzzhi1f7H_HYebriLcr4rvb8 ul6MLiKEPJd18Apz1PDFs4Yg_xT4P.g8aIwMBSUM7pkKgZp1u.eD9C8yTLduQwRr327U8q2qoqke 0epPBlkVz3kkj7QHjssFD03kZ9NZ9XUkNjycd3jM9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 28 Sep 2018 04:45:27 +0000 Date: Fri, 28 Sep 2018 04:45:25 +0000 (UTC) From: "Sam R." Reply-To: "samruohola@yahoo.com" To: "david.rowley@2ndquadrant.com" Cc: "pgsql-performance@lists.postgresql.org" , Jeff Janes Message-ID: <740776989.746571.1538109925380@mail.yahoo.com> In-Reply-To: References: <1321418371.5650982.1537346138600.ref@mail.yahoo.com> <1321418371.5650982.1537346138600@mail.yahoo.com> <954477769.6489282.1537348503194@mail.yahoo.com> <2104059362.5470282.1537368339686@mail.yahoo.com> <1685615979.2029662.1537857378862@mail.yahoo.com> Subject: Re: To keep indexes in memory, is large enough effective_cache_size enough? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_746570_1731760435.1538109925379" X-Mailer: WebService/1.1.12512 YahooMailAndroidMobile YMobile/1.0 (com.yahoo.mobile.client.android.mail/5.31.1; Android/8.1.0; OPR1.170623.026; B2N_sprout; HMD Global; Nokia 7 plus; 5.71; 2034x1080;) Content-Length: 4715 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk ------=_Part_746570_1731760435.1538109925379 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi! > The double buffering> itself does not slow anything down.=C2=A0 That was what I was suspecting a little. Double buffering may not matter in= our case, because the whole server is meant for PostgreSQL only. In our case, we can e.g. reserve almost "all memory" for PostgreSQL (shared= buffers etc.). Please correct me if I am wrong. BR Sam =20 =20 On ti, syysk. 25, 2018 at 23:55, David Rowley wrote: On Tue, 25 Sep 2018 at 18:36, Sam R. wro= te: > Regarding double buffering: I do not know how much double buffering would= slow down operations. > It could also be possible to turn off kernel page cache on our DB server,= to avoid double buffering. Although, we may still keep it in use. I think you've misunderstood double buffering.=C2=A0 The double buffering itself does not slow anything down. If the buffer is in shared buffers already then it does not need to look any further for it. Double buffering only becomes an issue when buffers existing 2 times in memory causes other useful buffers to appear 0 times. --=20 David Rowley=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services =20 ------=_Part_746570_1731760435.1538109925379 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi!

> The double= buffering
> itself does not slow anything down. 

That was what I was suspecting a litt= le. Double buffering may not matter in our case, because the whole server i= s meant for PostgreSQL only.

= In our case, we can e.g. reserve almost "all memory" for PostgreSQL (shared= buffers etc.).

Please co= rrect me if I am wrong.

BR Sa= m



On ti= , syysk. 25, 2018 at 23:55, David Rowley
<david.rowley@2ndquad= rant.com> wrote:
On Tue, 25 Sep 2018 at 18:36, Sam R. <samruohola@yahoo.com> wrote:

> Regarding double buffering= : I do not know how much double buffering would slow down operations.
> It could also be possible to turn off kernel page cache o= n our DB server, to avoid double buffering. Although, we may still keep it = in use.


I think you've misunders= tood double buffering.  The double buffering
itself = does not slow anything down. If the buffer is in shared buffers
already then it does not need to look any further for it. Double
buffering only becomes an issue when buffers existing 2 time= s in
memory causes other useful buffers to appear 0 times= .

--
David Rowley&= nbsp;                 http://www.2nd= Quadrant.com/
PostgreSQL Development, 24x7 Support, = Training & Services

------=_Part_746570_1731760435.1538109925379--