Re: Caching by Postgres

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Caching by Postgres
Date: 2005-08-23 21:17:42
Message-ID: 60oe7opd3d.fsf@dba2.int.libertyrms.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

mstone+postgres(at)mathom(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jignesh Shah 2005-08-23 21:29:01 Re: Read/Write block sizes (Was: Caching by Postgres)
Previous Message Chris Browne 2005-08-23 20:41:33 Re: Caching by Postgres