>>>>> "SK" == Sunitha Kambhampati <[EMAIL PROTECTED]> writes:
SK> A little background: Sometime earlier on the list, Dan posted a fix to
SK> make derby go faster with relaxed durability with some flags. The
SK> post is at
SK>
http://article.gmane.org/gmane.comp.apache.db.derby.user/681/match=relaxed+durability
I was originally planning to review this before it was committed, but
I did not get around to sending my comments before I went on a
vacation. Even if it is a bit late, here are some questions/comments
to this patch and the follow-up patch for the test program:
- I am not sure about the value of this mode compared to a mode with
relaxed durability, but guaranteed consistency. The large
performance improvements comes from not syncing transaction
commit. How much extra performance do you really get from not
doing one sync per checkpoint?
- Unless I am missing something, it does not seem more difficult to
implement the alternative that guarantees consistency. Do you
have any plans to do that?
- With respect to upgrade, does previous versions properly
initialize the spare byte in the log.ctrl file? Otherwise, one
could risk false detections on upgrade.
- I am a bit sceptical to the value of having a test that tests that
this feature give a certain performance advantage. I have seen
that over time such tests often have false failures when run on
new platforms. I see that your latest patch addresses this.
However, should the performance of disk io increase beyond your
threshold, the test would not be able to detect any failures to
turn off syncing. I think that a performance regression test
would be better for this prupose.
- The test will only test whether the syncing at commit is turned
off. The other syncs will not decrease performance so much that
it would be detected by the threshold of the test.
--
�ystein
