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

From Claudio Freire
Subject Re: Why we are going to have to go DirectIO
Date
Msg-id CAGTBQpb8-LR0QBTK_BNJZdZ_gi0ZdSmmhzq9h5Gjnh3pDN=cMA@mail.gmail.com
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
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: same-address mappings vs. relative pointers
Next
From: Peter Eisentraut
Date:
Subject: Re: Proposal: variant of regclass