[EMAIL PROTECTED] (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;;
"People who don't use computers are more sociable, reasonable, and ...
less twisted" -- Arthur Norman

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to