From: Chris Browne <cbbrowne@acm.org>
Subject: Re: Caching by Postgres
Date: Tue, 23 Aug 2005 17:17:42 -0400
Organization: cbbrowne Computing Inc
Lines: 24
Message-ID: <60oe7opd3d.fsf@dba2.int.libertyrms.com>
References: <20050823171045.12112.qmail@web51309.mail.yahoo.com>
	<20050823124323.710a9dd3.frank@wiles.org>
	<430B6DE3.6040109@sun.com> <200508231238.04844.josh@agliodbs.com>
	<20050823202932.GK8667@mathom.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.17 (Jumbo Shrimp, linux)
Cancel-Lock: sha1:RQHjE2QF6M4vONlqAnZ1A7VO1ho=
To: pgsql-performance@postgresql.org

mstone+postgres@mathom.us (Michael Stone) writes:
> On Tue, Aug 23, 2005 at 12:38:04PM -0700, Josh Berkus wrote:
>> which have a clear and measurable effect on performance and are
>> fixable without bloating the PG code.  Some of these issues (COPY
>> path, context switching
>
> Does that include increasing the size of read/write blocks? I've
> noticed that with a large enough table it takes a while to do a
> sequential scan, even if it's cached; I wonder if the fact that it
> takes a million read(2) calls to get through an 8G table is part of
> that.

But behind the scenes, the OS is still going to have to evaluate the
"is this in cache?" question for each and every one of those pages.
(Assuming the kernel's page size is 8K; if it's smaller, the number of
evaluations will be even higher...)

Grouping the read(2) calls together isn't going to have any impact on
_that_ evaluation.
-- 
let name="cbbrowne" and tld="ntlug.org" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/finances.html
"People who don't use computers are more sociable, reasonable, and ...
less twisted" -- Arthur Norman