Robert Haas <robertmhaas@gmail.com> wrote:
> I think it may also be tricky to make sure that a backend that
> needs to write a dirty buffer doesn't end up having to wait for a
> double-write to be fsync'd.
This and other parts of your post seem to ignore the BBU write-back
cache. Multiple fsyncs of a single page can still be collapsed at
that level to a single actual disk write. In fact, I rather doubt
this technology will look very good on machines without write-back
caching. I'm not as sure as you are that this is a net loss in
throughput, either. When the fsync storm clogs the RAID controller,
even reads stall, so something which more evenly pushes writes to
disk might avoid these non-productive pauses. I think that could
improve throughput enough to balance or exceed the other effects.
Maybe. I agree we need to be careful to craft a good set of
benchmarks here.
> Checksums aren't free even when using double-writes: if you don't
> have checksums, pages that have only hint bit-changes don't need
> to be double-written.
Agreed. Checksums aren't expected to be free under any
circumstances. I'm expecting DW to be slightly faster than FPW in
general, with or without in-page checksums.
> If double writes aren't going to give us anything "for free",
> maybe that's not the right place to be focusing our
> efforts...
I'm not sure why it's not enough that they improve performance over
the alternative. Making some other feature with obvious overhead
"free" seems an odd requirement to hang on this. (Maybe I'm
misunderstanding you on that point?)
-Kevin
