On Mon, 9 Sep 2002, Tom Lane wrote: > Curt Sampson <[EMAIL PROTECTED]> writes: > > On Mon, 9 Sep 2002, Tom Lane wrote: > >> ... We are trying to measure the behavior when kernel > >> caching is not helpful; if the database fits in RAM then you are just > >> naturally going to get random_page_cost close to 1, because the kernel > >> will avoid doing any I/O at all. > > > Um...yeah; another reason to use randread against a raw disk device. > > (A little hard to use on linux systems, I bet, but works fine on > > BSD systems.) > > Umm... not really; surely randread wouldn't know anything about > read-ahead logic?
Randread doesn't know anything about read-ahead logic, but I don't see how that matters one way or the other. The chances of it reading blocks sequentially are pretty much infinitesimal if you're reading across a reasonably large area of disk (I recommend at least 4GB), so readahead will never be triggered. > The reason this is a difficult topic is that we are trying to measure > certain kernel behaviors --- namely readahead for sequential reads --- > and not others --- namely caching, because we have other parameters > of the cost models that purport to deal with that. Well, for the sequential reads, the readahead should be trigerred even when reading from a raw device. So just use dd to measure that. If you want to slightly more accurately model postgres' behaviour, you probably want to pick a random area of the disk, read a gigabyte, switch areas, read another gigabyte, and so on. This will model the "split into 1GB" files thing. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
