Re: Why we are going to have to go DirectIO - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why we are going to have to go DirectIO
Date
Msg-id 16493.1386259189@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why we are going to have to go DirectIO  (Greg Stark <stark@mit.edu>)
Responses Re: Why we are going to have to go DirectIO  (Jim Nasby <jim@nasby.net>)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> I think the way to use mmap would be to mmap very large chunks,
> possibly whole tables. We would need some way to control page flushes
> that doesn't involve splitting mappings and can be efficiently
> controlled without having the kernel storing arbitrarily large tags on
> page tables or searching through all the page tables to mark pages
> flushable.

I might be missing something, but AFAICS mmap's API is just fundamentally
wrong for this.  The kernel is allowed to write-back a modified mmap'd
page to the underlying file at any time, and will do so if say it's under
memory pressure.  You can tell the kernel to sync now, but you can't tell
it *not* to sync.  I suppose you are thinking that some wart could be
grafted onto that API to reverse that, but I wouldn't have a lot of
confidence in it.  Any VM bug that caused the kernel to sometimes write
too soon would result in nigh unfindable data consistency hazards.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Metin Doslu
Date:
Subject: Re: Parallel Select query performance and shared buffers
Next
From: Metin Doslu
Date:
Subject: Re: Parallel Select query performance and shared buffers