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