> > 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
