Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance - Mailing list pgsql-hackers

From James Bottomley
Subject Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Date
Msg-id 1389718674.2192.41.camel@dabdike.int.hansenpartnership.com
Whole thread Raw
In response to Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, 2014-01-14 at 11:48 -0500, Robert Haas wrote:
> On Tue, Jan 14, 2014 at 11:44 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > No, I'm sorry, that's never going to be possible.  No user space
> > application has all the facts.  If we give you an interface to force
> > unconditional holding of dirty pages in core you'll livelock the system
> > eventually because you made a wrong decision to hold too many dirty
> > pages.   I don't understand why this has to be absolute: if you advise
> > us to hold the pages dirty and we do up until it becomes a choice to
> > hold on to the pages or to thrash the system into a livelock, why would
> > you ever choose the latter?  And if, as I'm assuming, you never would,
> > why don't you want the kernel to make that choice for you?
> 
> If you don't understand how write-ahead logging works, this
> conversation is going nowhere.  Suffice it to say that the word
> "ahead" is not optional.

No, I do ... you mean the order of write out, if we have to do it, is
important.  In the rest of the kernel, we do this with barriers which
causes ordered grouping of I/O chunks.  If we could force a similar
ordering in the writeout code, is that enough?

James





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Next
From: James Bottomley
Date:
Subject: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance