> > >The "this day and age" argument isn't very convincing. Hard drive 
> > >capacity growth has far outstripped hard drive seek time 
> and bandwidth improvements.
> > >Random access has more penalty than ever.
> >
> > In point of fact, there haven't been noticeable seek time 
> improvements 
> > for years. Transfer rates, on the other hand, have gone 
> through the roof.
> 
> Er, yeah. I stated it wrong. The real ratio here is between 
> seek time and throughput.
> 
> Typical 7200RPM drives have average seek times are in the 
> area of 10ms.
> Typical sustained transfer rates are in the range of 40Mb/s. 
> Postgres reads 8kB blocks at a time.
> 
> So 800kB/s for random access reads. And 40Mb/s for sequential 
> reads. That's a factor of 49. I don't think anyone wants 
> random_page_cost to be set to 50 though.
> 
> For a high end 15k drive I see average seek times get as low 
> as 3ms. And sustained transfer rates get as high as 100Mb/s. 
> So about 2.7Mb/s for random access reads or about a 
> random_page_cost of 37. Still pretty extreme.
> 
> So what's going on with the empirically derived value of 4? 
> Perhaps this is because even though Postgres is reading an 
> entire table sequentially it's unlikely to be the only I/O 
> consumer? The sequential reads would be interleaved 
> occasionally by some other I/O forcing a seek to continue.

What about the cache memory on the disk? Even IDE disks have some 8Mb
cache today, which makes a lot of difference for fairly short scans.
Even if it's just read cache. That'll bring the speed of random access
down to a 1=1 relationship with sequential access, assuming all fits in
the cache.


//Magnus

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to