Re: Why we are going to have to go DirectIO

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why we are going to have to go DirectIO
Дата
Msg-id 16493.1386259189@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why we are going to have to go DirectIO  (Greg Stark <stark@mit.edu>)
Ответы Re: Why we are going to have to go DirectIO  (Jim Nasby <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: Metin Doslu
Дата:
Сообщение: Re: Parallel Select query performance and shared buffers
Следующее
От: Metin Doslu
Дата:
Сообщение: Re: Parallel Select query performance and shared buffers