seunosewa@inaira.com (Seun Osewa) wrote:
> COMMIT; --> COMMIT SYNC; (guarantees atomic, consistent, durable
> write)
> COMMIT NOSYNC; --> (sacrifice durability of non-critical transaction
> for overall speed). So, the question is what people, especially those
> who have done DBMS work, think about this!
I think that whenever my organization cares THAT much about
performance, I'll probably be able to get enough budget to pay for a
SCSI RAID card that has battery backed cache that makes that issue go
away, as it allows the fsync() to become _nearly_ as fast as a no-op.
The case you suggest, where there are a lot of 'unimportant'
transactions, seems of dubious likelihood. If some updates "actually
commit," why shouldn't others? And if the users know they can't
really trust the "COMMIT NOSYNC" updates, won't it be tough to
convince them to trust the "really commited" stuff?
The battery backed cache idea winds up helping out _all_ updates, in a
HUGE way. That seems the way to go. At least in part because having
universal answers (e.g. - that helps ALL transactions) is likely to be
simpler than having everything be a special case.
--
(reverse (concatenate 'string "gro.gultn" "@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/spiritual.html
This is Linux country. On a quiet night, you can hear NT re-boot.
