On Mon, 2003-01-27 at 04:34, Curt Sampson wrote:
> On Mon, 27 Jan 2003, Sean Chittenden wrote:
>
> > The FreeBSD VM caching system does prevent one process from exhausting
> > another process's cached data due to a sequential access, but the
> > FreeBSD VM cache does not try to outsmart sequential data accesses to
> > datasets which are larger then available cache space because it's an
> > insanely difficult (impossible) problem to solve properly without
> > foreknowledge of what data elements will be accessed when.
>
> This is not impossible; Solaris does just this. I'm a little short of
Quite. One way to do it is:
- the OS notices that process X has been sequentially reading thru
file Y for, say, 3 seconds.
- the OS knows that X is currently at the mid-point of file Y
- OS says, "Hey, I think I'll be a bit more agressive about, when I
have a bit of time, trying to read Y faster than X is requesting
it
It wouldn't work well, though, in a client-server DB like Postgres,
which, in a busy multi-user system, is constantly hitting different
parts of different files.
The algorithm, though, is used in the RDBMS Rdb. It uses the algorithm
above, substituting "process X" for "client X", and passes the agressive
reads of Y on to the OS. It's a big win when processing a complete
table, like during a CREATE INDEX, or "SELECT foo, COUNT(*)" where
there's no index on foo.
--
+---------------------------------------------------------------+
| Ron Johnson, Jr. mailto:ron.l.johnson@cox.net |
| Jefferson, LA USA http://members.cox.net/ron.l.johnson |
| |
| "Fear the Penguin!!" |
+---------------------------------------------------------------+
