On 4/9/06, Tom Lane <[EMAIL PROTECTED]> wrote: > Certainly. If the OS has readahead logic at all, it ought to think that > a seqscan of a large table qualifies. Your arguments seem to question > whether readahead is useful at all --- but they would apply *just as > well* to an app doing its own readahead, which is what is really > getting proposed in this thread.
We know we're going to read the whole table, the OS doesn't. We can be confident that we're will not use our read-ahead when we're really doing random accesses. The OS has to deal with many applications with many workloads running on a wider spectrum of hardware. It's important that it does the right thing, but probably more important that it doesn't do the wrong thing. This encourages erroring on the side of small readahead. > Before we go replacing a standard OS-level facility with our own > version, we need to have a much clearer idea of why the OS isn't getting > the job done for us. Otherwise we're likely to write a large amount of > code and find out that it doesn't work very well either. Thats a fair position... It would be useful to know much much readahead PG needs in order to keep a high speed disk subsystem saturated. This would involve profiling how frequently PG requests data, how much it requests when running out of a hot cache. We could then say that the OS would need to readahead xMB to keep a yMB/s disk subsystem saturated. It would be good to know how much FBSD will readahead... It might also be interesting for someone with the right testing rig on linux to try the adaptive readahead patch to see if that improves PG's ability to keep the disk busy. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster