Zdenek Kotala wrote:
> Tom Lane wrote:
> > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> >> Tom Lane wrote:
> >>> If you only got 2% out of it, it's not even worth thinking about how to
> >>> fix the serious bugs that approach would create (primarily, lack of
> >>> control over when pages can get flushed to disk).
> >
> >> You can flush a pages by msync() function which writes dirty pages on
> >> disk. I don't see any other problem.
> >
> > Then you need to learn more. The side of the problem that is hard to
> > fix is that sometimes we need to prevent pages from being flushed to
> > disk until some other data (typically WAL entries) has reached disk.
> > With mmap'd data we have no control over early writes.
>
> I see. Thanks for explanation.
This is mentioned in the TODO list:
* Consider mmap()'ing files into a backend?
Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the
filealso causes mapping problems that might require mapping only individual pages, leading to thousands of mappings.
Anotherproblem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk
beforeWAL is written.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +