Re: [HACKERS] Re: [QUESTIONS] Does Storage Manager support >2GB tables?
ocie@paracel.com
From: ocie@paracel.com
To: dg@illustra.com (David Gould)
Cc: maillist@candle.pha.pa.us, scrappy@hub.org, chris@topdog.pas1.logicon.com, pgsql-hackers@postgreSQL.org
Date: 1998-03-12T22:57:35Z
Lists: pgsql-hackers
David Gould wrote: > > Bruce Momjian writes: > > I am adding this to the TODO list: > > > > * Do async I/O to do better read-ahead of data > > Good. > > > Because we are not threaded, we really can't do anything else while we > > are waiting for I/O, but we can pre-request data we know we will need. > > Threading is a bit like raw devices. It sounds like a really good idea, > particularly with M$ banging the "NT, now with threads" drum, but in real > life there are some very good reasons not to thread. Particularly with an > extensible product like Postgres where J-Random routine gets loaded at > runtime. In a threaded system, J-Random routine needs to be pretty well > perfect or the whole system comes down. In a process based system, unless > it trashes something in the shared memory, only the one connection instance > needs to come down. My experience with Illustra says that this is fairly > important. I tend to agree. I think threads are more usefull in applications software, where the programmer has at least some idea of the use of the program. On a more practical/implementation note, it might be nice to have one process that can perform prefetches for the others. I.E. If I know that I will need page X, I queue a request to this process (in shared memory?) and it will read in this page for us (or even write a page to disk for us). Asynchronous I/O is interesting, but I don't know how widely it has been implemented (Linux has none, unless the development version is working on it, and Solaris has aio, but not the POSIX flavor yet). Ocie Mitchell