Message-ID: <a7d2dc08d7c38948e3986a768c49684b8ab83f48.camel@cybertec.at>
Subject: Re: shared buffers
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Greg Rychlewski <greg.rychlewski@gmail.com>, pgsql-novice@postgresql.org
Date: Mon, 29 Mar 2021 19:09:02 +0200
In-Reply-To: 
 <CAKemG7UgmsEQUmD74_CCKy5ahyEd8yWSt-Nr7BXNcZ=MKSLcRg@mail.gmail.com>
References: 
	<CAKemG7UgmsEQUmD74_CCKy5ahyEd8yWSt-Nr7BXNcZ=MKSLcRg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/a7d2dc08d7c38948e3986a768c49684b8ab83f48.camel%40cybertec.at>
Precedence: bulk

On Mon, 2021-03-29 at 11:27 -0400, Greg Rychlewski wrote:
> Will every page touched during a table or index scan, even if it's
>  not going to be used in the final result, be loaded into shared buffers? 
> 
> i.e. if you need to evaluate a filter condition, will it load that page
>  into shared buffers and then evaluate it from there?

Even if a value does not appear in a query result, the page containing it
has to be read, if the value is used for calculating the query result.

All pages read are loaded into shared buffers.  So yes, they will be loaded.

Note that there is an optimization for big sequential scans:  if the table
scanned is bigger than a quarter of shared buffers, PostgreSQL will use a
small ring buffer to read the table.  This prevents a large sequential scan
from blowing out your cache, since it uses the same buffers to scan
the whole table.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com