From: James Mansion <james@mansionfamily.plus.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: jd@commandprompt.com, Scott Marlowe <scott.marlowe@gmail.com>
Cc: Steve Crawford <scrawford@pinpointresearch.com>
Cc: pgsql-performance@postgresql.org, Ben Chobot <bench@silentmedia.com>
Subject: Re: BBU Cache vs. spindles
Date: Thu, 28 Oct 2010 21:33:19 +0100
Message-ID: <4CC9DE0F.50401@mansionfamily.plus.com> (raw)
In-Reply-To: <16724.1287952819@sss.pgh.pa.us>
References: <4CC04EA50200002500036C5E@gw.wicourts.gov>
<201010211935.o9LJZTM21744@momjian.us>
<4CC0513E0200002500036C68@gw.wicourts.gov>
<4CC3E8BF.4090409@mansionfamily.plus.com>
<4CC46479.2050206@2ndquadrant.com>
<16724.1287952819@sss.pgh.pa.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: james@mansionfamily.plus.com, tgl@sss.pgh.pa.us, greg@2ndquadrant.com, Kevin.Grittner@wicourts.gov, bruce@momjian.us, scott.marlowe@gmail.com, scrawford@pinpointresearch.com, bench@silentmedia.com
Subject: Re: BBU Cache vs. spindles
In-Reply-To: <4CC9DE0F.50401@mansionfamily.plus.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox