Re: Large tables (was: RAID 0 not as fast as

> > Do you think that adding some posix_fadvise() calls to the backend
to
> > pre-fetch some blocks into the OS cache asynchroneously could
improve
> > that situation?
>
> Nope - this requires true multi-threading of the I/O, there need to be
> multiple seek operations running simultaneously.  The current executor
> blocks on each page request, waiting for the I/O to happen before
> requesting
> the next page.  The OS can't predict what random page is to be
requested
> next.
>
> We can implement multiple scanners (already present in MPP), or we
could
> implement AIO and fire off a number of simultaneous I/O requests for
> fulfillment.

So this might be a dumb question, but the above statements apply to the
cluster (e.g. postmaster) as a whole, not per postgres
process/transaction correct? So each transaction is blocked waiting for
the main postmaster to retrieve the data in the order it was requested
(i.e. not multiple scanners/aio)?

In this case, the only way to take full advantage of larger hardware
using normal postgres would be to run multiple instances? (Which might
not be a bad idea since it would set your application up to be able to
deal with databases distributed on multiple servers...)

- Bucky