"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
>> I don't know how to do that --- AFAICS, getting trustworthy numbers by
>> measurement would require hundreds of meg of temporary disk space and
>> probably hours of runtime. (A smaller test would be completely
>> corrupted by kernel disk caching effects.)
> Getting a rough estimate of CPU speed is trivial. Getting a rough estimate
> of sequential disk access shouldn't be too hard, though you would need to
> make sure it didn't give the wrong answer if you ran configure twice in a
> row or something. Getting a rough estimate of disk access for a single
> non-sequential disk page also shouldn't be too hard with the same caviats.
In practice this would be happening at initdb time, not configure time,
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.
regards, tom lane