Re: [HACKERS] Some notes on optimizer cost estimates - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: [HACKERS] Some notes on optimizer cost estimates
Date
Msg-id 388CD890.494E6754@tm.ee
Whole thread Raw
In response to Re: [HACKERS] Some notes on optimizer cost estimates  ("Henry B. Hotz" <hotz@jpl.nasa.gov>)
List pgsql-hackers
Don Baccus wrote:
> 
> At 01:13 PM 1/24/00 -0500, Tom Lane wrote:
> 
> >In practice this would be happening at initdb time, not configure time,

or perhaps it can be collected when running regression tests.

> >since it'd be a lot easier to do it in C code than in a shell script.
> >But that's a detail.  I'm still not clear on how you can wave away the
> >issue of kernel disk caching --- if you don't use a test file that's
> >larger than the disk cache, ISTM you risk getting a number that's
> >entirely devoid of any physical I/O at all.
> 
> And even the $100 6.4 GB Ultra DMA drive I bought last week has
> 2MB of cache.  hdparm shows me getting 19 mB/second transfers
> even though it adjusts for the file system cache.  It's only a
> 5400 RPM disk and I'm certain the on-disk cache is impacting
> this number.

But they also claim internal bitrates of more than 250 Mbits/s, which stays 
the same for both 5400 and 7200 RPM disks (the latter even have the same 
seek time) so that may actually be true for sequential reads if they have 
all their read paths at optimal efficiency and readahead and cache do 
their job.

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


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] Happy column dropping
Next
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] Well, then you keep your darn columns