Steve writes:
> TPC-C certainly seems doable, though it would require practices that most
> TurboIMAGE developers seem to avoid, like locking around reads.
> However, one item concerns me: the "checkpoint" rules. Specifically,
> 5.5.2.2.3 requires that "The Checkpoint Interval must be less than or
> equal to the Measurement Interval.  If the Checkpoint Interval is less
> than the Measurement Interval, the Measurement Interval must be an
> integral multiple of the Checkpoint Interval." MPE with XM qualifies
> as checkpointing as defined by the TPC-C spec, but it doesn't have a
> fixed time interval for the checkpoint writes.

Sounds as though all we have to do is make sure that an XM log post has
occurred after the last update and before the end of the measurement
interval.  This may only need to be an ordinary XM post as opposed to a full
volume checkpoint, and I think posts occur within 1/5 second or something
like that these days if for no other reason (and closing the database at the
end of the run probably ensures that everything is posted to XM which is all
I *think* they care about).

They're obviously trying to make sure that the database engine isn't just
buffering up all the updates to be committed at some point after you've
stopped the stopwatch, but Image doesn't have a background database engine
to keep things around after the programs terminate, so once we've DBCLOSEd,
there's really nothing else pending.  It doesn't sound like a big problem to
me.  We could probably find a way to force a full volume set
checkpoint/flush if that were required for some reason.

> OTOH, TPC-D seems to be a non-starter;

My impression of TPC-D is that it was a bunch of commercial apps being run
in batch mode specifically as a data mining / decision support application,
which doesn't sound like an "interesting" benchmark for the 3000, at least
compared to TPC-C which is specifically online transaction processing, which
I would guess is what we all think the 3000's strength is.

G.