From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Safe/Fast I/O ...
Date: Mon, 13 Apr 1998 12:26:59 -0400 (EDT)
Message-ID: <199804131626.MAA25613@khavrinen.lcs.mit.edu> (raw)
[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.]
Michal Mosiewicz <mimo@interdata.com.pl> writes:
> The main reason of using memory mapping is that you don't have to create
> unnecessary buffers. Normally, for every operation you have to create
> some in-memory buffer, copy the data there, do some operations, put the
> data back into file. In case of memory mapping you may avoid of creating
> of unnecessary buffers, and moreover you may call your system functions
> less frequently. There are also additional savings. (Less memory
> copying, reusing memory if several processes map the same file)
Additionally, 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. (A good system will also provide other benefits, such as
pre-faulting and extended read ahead.)
Of course, it does have one significant drawback: memory-mapped regions
do not automatically extend when their underlying files do. So, for
interacting with a structure that shows effectively linear access and
growth, asynchronous I/O is more likely to be a benefit, since AIO can
extend a file asynchronously, whereas other mechanisms will block
while the file is being extended. (Depending on the system, this may
not be true for multi-threaded programs.)
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
wollman@lcs.mit.edu | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
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: wollman@khavrinen.lcs.mit.edu
Subject: Re: [HACKERS] Safe/Fast I/O ...
In-Reply-To: <199804131626.MAA25613@khavrinen.lcs.mit.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