I don't know if this message has been bouncing around the internet &
Usenet for a while or Stan just got back to this but thanks to him for
hard data and the analysis of the technical implications.

Stan Sieler responded to a question about low level file access, in
this case access from the Posix system.

<snip>
> Using MR/NOBUF (18 writes):
>    plain       CPU =   180, elapsed     207 milliseconds.
>    XM          CPU =   405, elapsed   2,022 milliseconds.
>    fcontrol 2  CPU =   168, elapsed     765 milliseconds. (18 calls)
>
> Using ordinary record writes (14,033 writes):
>    plain       CPU = 1,395, elapsed   1,440 milliseconds.
>    XM          CPU = 9,246, elapsed  10,471 milliseconds.
>    fcontrol 2  CPU = 9,913, elapsed 118,472 milliseconds.
>
<snip>
> In this case, XM means you're data is serially protected.
>
> I.e., if you write records A, B, C, D, and then the system fails,
> after system recovery, you'll have none, or A, or A & B, or A & B &
C,
> or A & B & C & D ... but no other combination (e.g., A & D).
>
> But, notice that even though you knew you got as far as writing D,
> and perhaps even told the user that ... and they called their broker
and
> did something with that information ...
> it wasn't necessarily on disk...and got could have been lost!
>
> With fcontrol 2, you know the data is on disk when you come back
> from the fcontrol 2 call.
<END>

To pick up on an old thread . . .   I think this illustrates why it
doesn't make sense to compare data access with minimal recovery and
integrity protection with more protected data access.    For data
access in a Image database context the best *information* protection
offered comes from using the dynamic rollback capability (DBXBEGIN /
DBXEND on logical transactions).    Much of the competition in the
database world uses a similar level of protection.

To reduce this line of thinking to the extreme,  if you want really
fast database performance, you should ask HP to bypass the XM and use
the much faster "plain" record writing technique instead.   Lets start
a campaign!

The Moral of the Story.    Any database performance comparison that
doesn't specify the levels of recovery and integrity protection in use
by both database management systems should be considered highly
suspect.     And that principle applies to comparisions between the HP
e3000 and other platforms.    IMO anything else is unprofessional
(disseminating bad information) which is why I become concerned when I
hear it done.

Cortlandt Wilson
Cortlandt Software
Mountain View, CA
(650) 966-8555
http://www.cortsoft.com    (MANMAN Resources Guide)