Re: Support Parallel Query Execution in Executor

On 4/9/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.