Skip site navigation (1) Skip section navigation (2)

Re: BBU Cache vs. spindles

From: david(at)lang(dot)hm
To: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Bruce Momjian <bruce(at)momjian(dot)us>, jd(at)commandprompt(dot)com, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Steve Crawford <scrawford(at)pinpointresearch(dot)com>, pgsql-performance(at)postgresql(dot)org, Ben Chobot <bench(at)silentmedia(dot)com>
Subject: Re: BBU Cache vs. spindles
Date: 2010-10-29 21:14:26
Message-ID: alpine.DEB.2.00.1010291412030.13891@asgard.lang.hm (view raw or flat)
Thread:
Lists: pgsql-performancepgsql-www
On Fri, 29 Oct 2010, James Mansion wrote:

> Tom Lane wrote:
>> Uh, no, it is not.  The difference is that we can update a byte in a
>> shared buffer, and know that it *isn't* getting written out before we
>> 
> Well, I don't know where yu got the idea I was refering to that sort of thing 
> - its
> the same as writing to a buffer before copying to the mmap'd area.
>> It's true that we don't know whether write() causes an immediate or
>> delayed disk write, but we generally don't care that much.  What we do
>> 
> Which is what I was refering to.
>> care about is being able to ensure that a WAL write happens before the
>> data write, and with mmap we don't have control over that.
>>
>> 
> I think you have just the same control either way, because you can only force 
> ordering
> with an appropriate explicit sync, and in the absence of such a sync all bets 
> are off for
> whether/when each disk page is written out, and if you can't ensure that the 
> controller
> and disk are write through you'd better do a hardware cache flush.too, right?
>
> A shame that so many systems have relatively poor handling of that hardware 
> flush.

the issue is that when you update a mmaped chunk of data, it could be 
written out immediatly without you doing _anything_ (and thanks to 
multiple cores/threads, it could get written out while you are still in 
the middle of updating it). When you update an internal buffer and then 
write that, you know that nothing will hit the disk before you issue the 
write command.

David Lang

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2010-10-29 21:17:30
Subject: Re: Slow Query- Bad Row Estimate
Previous:From: Josh BerkusDate: 2010-10-29 21:09:37
Subject: Re: Slow Query- Bad Row Estimate

pgsql-www by date

Next:From: Josh KupershmidtDate: 2010-10-30 00:54:13
Subject: HTML 4.01 docs + xhtml header on postgresql.org
Previous:From: James MansionDate: 2010-10-29 20:52:30
Subject: Re: BBU Cache vs. spindles

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group