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

Re: BBU Cache vs. spindles

From: James Mansion <james(at)mansionfamily(dot)plus(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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-28 20:33:19
Message-ID: 4CC9DE0F.50401@mansionfamily.plus.com (view raw or flat)
Thread:
Lists: pgsql-performancepgsql-www
Tom Lane wrote:
> The other and probably worse problem is that there's no application
> control over how soon changes to mmap'd pages get to disk.  An msync
> will flush them out, but the kernel is free to write dirty pages sooner.
> So if they're depending for consistency on writes not happening until
> msync, it's broken by design.  (This is one of the big reasons we don't
> use mmap'd space for Postgres disk buffers.)
>   
Well, I agree that it sucks for the reason you give - but you use write 
and that's *exactly* the
same in terms of when it gets written, as when you update a byte on an 
mmap'd page.

And you're quite happy to use write.

The only difference is that its a lot more explicit where the point of 
'maybe its written and maybe
it isn't' occurs.

There need be no real difference in the architecture for one over the 
other: there does seem to be
evidence that write and read can have better forward-read and 
write-behind behaviour, because
read/write does allow you to initiate an IO with a hint to a size that 
exceeds a hardware page.

And yes, after getting into the details while starting to port TC to 
Windows, I decided to bin
it.  Especially handy that SQLite3 has WAL now.  (And one last dig - TC 
didn't even
have a checksum that would let you tell when it had been broken: but it 
might all be fixed now
of course, I don't have time to check.)

James


In response to

Responses

pgsql-performance by date

Next:From: Joshua D. DrakeDate: 2010-10-28 20:48:32
Subject: Re: partitioning question 1
Previous:From: Reid ThompsonDate: 2010-10-28 20:08:43
Subject: Re: partitioning question 1

pgsql-www by date

Next:From: Tom LaneDate: 2010-10-28 21:26:17
Subject: Re: BBU Cache vs. spindles
Previous:From: Rob WultschDate: 2010-10-28 03:43:52
Subject: Re: BBU Cache vs. spindles

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