Re: Why we are going to have to go DirectIO

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: Why we are going to have to go DirectIO
Дата
Msg-id CAGTBQpb8-LR0QBTK_BNJZdZ_gi0ZdSmmhzq9h5Gjnh3pDN=cMA@mail.gmail.com
обсуждение исходный текст
Ответ на 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
Список pgsql-hackers
On Thu, Dec 5, 2013 at 11:42 AM, Greg Stark <stark@mit.edu> wrote:
> (b) is the way more interesting research project though. I don't think
> anyone's tried it and the kernel interface to provide the kinds of
> information Postgres needs requires a lot of thought. If it's done
> right then Postgres wouldn't need a buffer cache manager at all. It
> would just mmap the entire database and tell the kernel when it's safe
> to flush buffers and let the kernel decide when based on when it's
> convenient for the hardware.


That's a bad idea in the current state of affairs. MM files haven't
been designed for that usage, and getting stable performance out of
that will be way too difficult.

systemd's journal is finding that out the hard way. It uses mmap too.

Having the buffer manager mmap buffers into its shared address space,
however, might be an interesting idea to pursue. However, one must not
forget that the kernel has similar scalability issues when the number
of memory mappings increase arbitrarily.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: same-address mappings vs. relative pointers
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Proposal: variant of regclass