Re: [HACKERS] Some notes on optimizer cost estimates

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Some notes on optimizer cost estimates
Date: 2000-01-24 22:56:16
Message-ID: 388CD890.494E6754@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-01-24 23:00:05 Re: AW: [HACKERS] Some notes on optimizer cost estimates
Previous Message Hannu Krosing 2000-01-24 22:43:41 Re: [HACKERS] Happy column dropping