Zdenek Kotala wrote: > Tom Lane wrote: > > Zdenek Kotala <[EMAIL PROTECTED]> 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 file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
