From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ron <ronljohnsonjr@gmail.com>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: need suggestion on querying big tables
In-reply-to: <d926084d-63a7-854b-2d8d-459d33ec7f70@gmail.com>
References: 
 <CAJuN1jj6NQDUjbMH=n4zry10JMJEZ8bRi=j6uA-3_108-Tq9cQ@mail.gmail.com>
 <d926084d-63a7-854b-2d8d-459d33ec7f70@gmail.com>
Comments: In-reply-to Ron <ronljohnsonjr@gmail.com>
	message dated "Tue, 06 Dec 2022 08:51:21 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3617536.1670338992.1@sss.pgh.pa.us>
Date: Tue, 06 Dec 2022 10:03:12 -0500
Message-ID: <3617537.1670338992@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3617537.1670338992%40sss.pgh.pa.us>
Precedence: bulk

Ron <ronljohnsonjr@gmail.com> writes:
> You've set effective_cache_size to 83%, when it should be at most 20%.

I think you're confusing effective_cache_size with the size of
shared buffers.  It's meant to be an estimate of the total disk
cache space available, in both shared buffers and OS caches.

In any case, it's a fairly spongy parameter.  It doesn't correspond
to any allocation actually made or requested in Postgres; it just
serves to tweak the planner's guesses about how expensive repeated
indexscans are likely to be.  83% of available RAM might be too
much, but it's probably not causing any real problems.

			regards, tom lane