Re: Sequential Scan Read-Ahead - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Sequential Scan Read-Ahead
Date
Msg-id 1019756479.7943.17.camel@taru.tm.ee
Whole thread Raw
In response to Re: Sequential Scan Read-Ahead  (Curt Sampson <cjs@cynic.net>)
List pgsql-hackers
On Thu, 2002-04-25 at 12:47, Curt Sampson wrote:
> On Thu, 25 Apr 2002, Lincoln Yeoh wrote:
> 
> > I think the raw partitions will be more trouble than they are worth.
> > Reading larger chunks at appropriate circumstances seems to be the "low
> > hanging fruit".
> 
> That's certainly a good start. I don't know if the raw partitions
> would be more trouble than they are worth, but it certainly would
> be a lot more work, yes. One could do pretty much as well, I think,
> by using the "don't buffer blocks for this file" option on those
> OSes that have it.

I was on a short DB2 tuning course and was told that on Win NT turning
off cache causes about 15-20% speedup. 

(I don't know what exacly is sped up :)

> > [1] The theory was the drive typically has to jump around a lot more for
> > metadata than for files. In practice it worked pretty well, if I do say so
> > myself :). Not sure if modern HDDs do specialized O/S metadata caching
> > (wonder how many megabytes would typically be needed for 18GB drives :) ).
> 
> Sure they do, though they don't necessarially read it all. Most
> unix systems

Do modern HDD's have unix inside them ;)

> have special cache for namei lookups (turning a filename
> into an i-node number), often one per-process as well as a system-wide
> one. And on machines with a unified buffer cache for file data,
> there's still a separate metadata cache.

-----------
Hannu




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Vote totals for SET in aborted transaction
Next
From: Neil Conway
Date:
Subject: Re: md5 passwords and pg_shadow