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 CAGTBQpZbcTWzDGN99zF+Dt5giTMspBh_8_ukbVV5aeQ82V5UbA@mail.gmail.com
Whole thread Raw
In response to Re: Why we are going to have to go DirectIO  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Tue, Dec 10, 2013 at 11:33 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tuesday, December 10, 2013, Tom Lane wrote:
>>
>> Jeff Janes <jeff.janes@gmail.com> writes:
>> > On Tue, Dec 3, 2013 at 11:39 PM, Claudio Freire
>> > <klaussfreire@gmail.com>wrote:
>> >> Problem is, Postgres relies on a working kernel cache for checkpoints.
>> >> Checkpoint logic would have to be heavily reworked to account for an
>> >> impaired kernel cache.
>>
>> > I don't think it would need anything more than a sorted checkpoint.
>>
>> Nonsense.  We don't have access to the physical-disk-layout information
>> needed to do reasonable sorting; to say nothing of doing something
>> intelligent in a multi-spindle environment, or whenever any other I/O
>> is going on concurrently.
>
>
> The proposal I was responding to was simply to increase shared_buffers to
> 80% of RAM *instead of* implementing directIO.


If you do not leave a reasonable amount of RAM, writes will be direct
and synchronous.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why the buildfarm is all pink
Next
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] Add transforms feature