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 <pgsql-performance-owner+archive@lists.postgresql.org>)
	id 1g2YVj-00010Q-Ib
	for pgsql-performance@arkaria.postgresql.org; Wed, 19 Sep 2018 09:11:03 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-performance-owner+archive@lists.postgresql.org>)
	id 1g2YVh-0007FR-5s
	for pgsql-performance@arkaria.postgresql.org; Wed, 19 Sep 2018 09:11:01 +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 <sk@zsrv.org>)
	id 1g2YVg-0007FK-Ri
	for pgsql-performance@lists.postgresql.org; Wed, 19 Sep 2018 09:11:00 +0000
Received: from forward2j.cmail.yandex.net ([5.255.227.20])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.89)
	(envelope-from <sk@zsrv.org>)
	id 1g2YVc-0003wr-Vd
	for pgsql-performance@lists.postgresql.org; Wed, 19 Sep 2018 09:10:59 +0000
Received: from mxback15g.mail.yandex.net (mxback15g.mail.yandex.net
 [IPv6:2a02:6b8:0:1472:2741:0:8b7:94])
	by forward2j.cmail.yandex.net (Yandex) with ESMTP id 4AD0E2188E;
	Wed, 19 Sep 2018 12:10:53 +0300 (MSK)
Received: from localhost (localhost [::1])
	by mxback15g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id
 juAsivsXJu-AqQWsKsS;
	Wed, 19 Sep 2018 12:10:52 +0300
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zsrv.org; s=mail;
 t=1537348252;
	bh=xuRNUF40ob4Fw7Mq9H39tkId/9eLbTgMKJUb3Xi7fds=;
	h=From:To:In-Reply-To:References:Subject:Date:Message-Id;
	b=uyF/ayeV3hTg1TVtMXM0VcjK3j+88mxiCStjUUG1HyFcIBPSMLE1QwoufYQNMqL3H
	 Kl4EgB48gaQrgPOwcbJqFaRv6ct03+E4OUpyFXPVmdL17N1G2YdKe8LbHlFPWodWxX
	 AKKX148q8lhlBU/5ocO/ekREM88e93mtWCI5YmQE=
Authentication-Results: mxback15g.mail.yandex.net;
 dkim=pass header.i=@zsrv.org
Received: by sas1-fed4e4c8a570.qloud-c.yandex.net with HTTP;
	Wed, 19 Sep 2018 12:10:52 +0300
From: Sergei Kornilov <sk@zsrv.org>
To: Sam R. <samruohola@yahoo.com>,
	"pgsql-performance@lists.postgresql.org"
 <pgsql-performance@lists.postgresql.org>
In-Reply-To: <1321418371.5650982.1537346138600@mail.yahoo.com>
References: <1321418371.5650982.1537346138600.ref@mail.yahoo.com>
 <1321418371.5650982.1537346138600@mail.yahoo.com>
Subject: Re: To keep indexes in memory,
 is large enough effective_cache_size enough?
MIME-Version: 1.0
X-Mailer: Yamail [ http://yandex.ru ] 5.0
Date: Wed, 19 Sep 2018 12:10:52 +0300
Message-Id: <5456011537348252@sas1-fed4e4c8a570.qloud-c.yandex.net>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
List-Id: <pgsql-performance.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-performance@lists.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-performance>
Precedence: bulk

Hi

effective_cache_size is not cache. It is just approx value for query planner: how many data can be found in RAM (both in shared_buffers and OS page cache)

> Q: Size of shared_buffers does not matter regarding keeping index in memory?
shared_buffers is cache for both tables and indexes pages. All data in tables and indexes are split to chunks 8 kb each - pages (usually 8kb, it can be redefined during source compilation).
Shared buffers cache is fully automatic, active used pages keeps in memory, lower used pages may be evicted. You can not pin any table or index to shared buffers.

regards, Sergei