Re: Async I/O

I'm sure you've probably thought about this (and discarded it for
a variety of reasons), but here it goes anyway:

Have some daemon ("postmaster" itself, perhaps) service requests for
pages asynchronously. For example, have each "postgres" client request
the pages from "postmaster" and continue running; "postmaster" could
service the request, map the resulting pages into the shared segment, and
notify the appropriate "postgres" client (either through the socket
or some other way) asynchronously. The "postgres" client could then
be checking the socket with a non-blocking select whenever it wanted to.
(Or you could notify the client with a signal telling it that the request
has been serviced and it can go and get the pages.)

It's just a suggestion. Good luck and congratulations for the excellent
work you've done with postgresql.

-Ted.

p.s. I've got a table that's 77 MB (340,000 records), with six indexes on
it totaling another 66 MB. It does pretty well, actually.

Above is a very good review of a platform-independent way for us to do
async read-aheads, particularly for heap reads from indexes. I think it
deserves consideration as a good way to perform what we need done.

Shared memory certainly gives us a way to communicate between these
processes.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)