From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Shaun Thomas <sthomas(at)optionshouse(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: high io BUT huge amount of free memory |
Date: | 2013-05-03 15:34:48 |
Message-ID: | CAM-w4HNp_LK0a-YWxG30993PYQ8W_bs0Ks6_yfNopg-sPU4_Ag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 3, 2013 at 12:09 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> But that brings up an interesting question. How hard / feasible would it be
>> to add DIO functionality to PG itself?
>
> I don't think there is too much chance of that - but I also don't really
> see the point in trying to do it. We should start by improving postgres
> buffer writeout which isn't that great, especially with big shared
> buffers. We would have to invest quite a lot of work in how our
> buffering and writeout works to make DIO perform nicely.
I think eventually we'll probably go that route. Double-buffering is
just too expensive not to solve one way or the other. The other is
using mmap and somehow solving the WAL ordering issue which would be
nice but seems even less likely to succeed.
The problem with DIO which has been covered many times in the past
here is that then we need to learn a lot about the hardware. It would
be up to us to schedule i/o efficiently for the hardware layout which
is not an easy problem especially if we're not always the only
consumer of that hardware bandwidth.
I don't think it's worth going through the discussions again unless
someone is actually interested in writing the code and has new ideas
on how to solve these problems.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-05-03 15:56:29 | Re: Remaining beta blockers |
Previous Message | Andres Freund | 2013-05-03 15:24:54 | Re: Remaining beta blockers |