Hi Christopher,
Just to go through your points.
> > 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.
I agree, but I would not want to throw hardware at something that can be
easily implemented with software. I think the functionality is in
about every RDBMS today, just not under the database users' control.
> 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?
I feel, if people have the choice they would feel free to use the DBMS
for some functions they don't use it for now cause of the limited update
speeds without battery backup. For example, Microsoft ASP.NET docs re-
peat that its slower to use a database to manage visitor sessions. In
many cases I can afford to risk "forgetting" information about the act-
ivity of a user (out of thousands) who visited a shopping site without
ordering anything. The ASP.NET script would get to choose which COMMIT
to use depending on a number of factors.
> 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?
Actually, I see it the other way round. The existence of
COMMIT NOSYNC (faster, not durable in case of crash)
should remind users that the other COMMIT [SYNC] though
slower, is durable.
> 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.
I think if database programmers have it,
they will use it to optimize their applications.
Aside from increased speed there is the possibility people
will just get to do some things they have just not been
doing. I think its a nice concept, which can be exploited
for performance if implemented in a RdBMS.
Seun Osewa.
