From: aoki@CS.Berkeley.EDU
To: pgsql-hackers@hub.org
Cc: wollman@khavrinen.lcs.mit.edu
Subject: Re: [HACKERS] Safe/Fast I/O ...
Date: Tue, 14 Apr 98 15:25:47 -0700
Message-ID: <199804142225.PAA14489@faerie.CS.Berkeley.EDU> (raw)
In-Reply-To: <199804141528.LAA09003@hub.org>
> Date: Mon, 13 Apr 1998 12:26:59 -0400 (EDT)
> From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
> Subject: Re: [HACKERS] Safe/Fast I/O ...
>
> [Please forgive me for the way this post is put together; I'm not
> actually on your mailing-list, but was just perusing the archives.]
> if your operating system is at all reasonable, using
> memory mapping allows you to take advantage of all the work that has
> gone into tuning your VM system. If you map a large file, and then
> access in some way that shows reasonable locality, the VM system will
> probably be able to do a better job of page replacement on a
> system-wide basis than you could do with a cache built into your
> application.
not necessarily. in this case, the application (the database) has
several very different page access patterns, some of which (e.g.,
non-boustrophedonic nested-loops join, index leaf accesses) *do not*
exhibit reasonable locality and therefore benefit from the ability to
turn on hate-hints or MRU paging on a selective basis. database query
processing is one of the classic examples why "one size does not fit
all" when it comes to page replacement -- no amount of "tuning" of an
LRU/clock algorithm will help if the access pattern is wrong.
stonebraker's 20-year-old CACM flame on operating system services for
databases has motivated a lot of work, e.g., microkernel external
pagers and the more recent work at stanford and princeton on
application-specific paging, but many older VM systems still don't
have a working madvise().. meaning that a *portable* database still
has to implement its own buffer cache if it wants to exploit its
application-specific paging behavior.
--
Paul M. Aoki | University of California at Berkeley
aoki@CS.Berkeley.EDU | Dept. of EECS, Computer Science Division #1776
| Berkeley, CA 94720-1776
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: aoki@CS.Berkeley.EDU, pgsql-hackers@hub.org, wollman@khavrinen.lcs.mit.edu
Subject: Re: [HACKERS] Safe/Fast I/O ...
In-Reply-To: <199804142225.PAA14489@faerie.CS.Berkeley.EDU>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox