Re: Caching by Postgres - Mailing list pgsql-performance

From Chris Browne
Subject Re: Caching by Postgres
Date
Msg-id 60oe7opd3d.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Caching by Postgres  (gokulnathbabu manoharan <gokulnathbabu@yahoo.com>)
List pgsql-performance
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

pgsql-performance by date:

Previous
From: Chris Browne
Date:
Subject: Re: Caching by Postgres
Next
From: Jignesh Shah
Date:
Subject: Re: Read/Write block sizes (Was: Caching by Postgres)