Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> You would still however get the advantage that you wouldn't have to copy the
> data from the disk buffers to user space, you simply get the disk buffer
> mapped into your address space.
AFAICS this would be the *only* advantage. While it's not negligible,
it's quite unclear that it's worth the bookkeeping and portability
headaches of managing lots of mmap'd areas, either.
Before I take this idea seriously at all, I'd want to see a design that
addresses a couple of critical issues:
1. Postgres' shared buffers are *shared*, potentially across many
processes. How will you deal with buffers for files that have been
mmap'd by only some of the processes? (Maybe this means that the
whole concept of shared buffers goes away, and each process does its
own buffer management based on its own mmaps. Not sure. That would be
a pretty radical restructuring though, and would completely invalidate
our present approach to page-level locking.)
2. How do you deal with extending a file? My system's mmap man page
says
If the size of the mapped file changes after the call to mmap(), the
effect of references to portions of the mapped region that correspond
to added or removed portions of the file is unspecified.
This suggests that the only portable way to cope is to issue a separate
mmap for every disk page. Will typical Unix systems perform well with
umpteen thousand small mmap requests?
3. How do you persuade the other backends to drop their mmaps of a table
you are deleting?
There are probably other gotchas, but without an understanding of how
to address these, I doubt it's worth looking further ...
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
