Robert Haas <robertmh...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers