Regarding Oracle:
It also batches commits... This means that if two or more users submit commits
concurrently (or near the same interupt ) then those will be serviced at the
same time.
But oracle differs significantly from sqlite, in its architecture as it would
not be appropriate for an embedded DB..
Christian Smith <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] uttered:
>
> It takes at least two complete rotations of the disk platter
> to do an atomic and durable commit. On a 7200 RPM disk, that
> means 60 transactions per second is your speed of light.
>
> Your question boils down to this: Can you speed up transactions
> by dropping the durable property - the D in ACID. Yes you
> can. Actually, most client/server database engines already
> do this for you without telling you. Very few client/server
> databases are really ACID - they are usually on ACI when
> confronted with a power failure.
Are you sure about this? I'm pretty sure PostgreSQL is ACID by default,
and as certain as I can be without proof that the commercial (Oracle etc.)
are as ACID as the hardware they run on.
They achieve this by not requiring seeks to overwrite data, as the write
ahead log is sequential and so can be written at the sequential IO rate of
the underlying device in the best case.
The client/server databases are also not limited by the filesystem
synchronous metadata updates, and so are more likely to achieve the peak
IO rate of the underlying device.
>
> [snip]
>
> A second approach would be to overload the OS drivers on
> the backend of SQLite to support asynchronous I/O. Mozilla
> does this in Firefox in order to boost performance on NFS.
> There is well-commented sample code showing how to do this
> in the SQLite source file "test_async.c". That sample code
> does not combine multiple transactions, but you could probably
> tweak it to make that happen.
When doing some performance testing between different FS on Linux, I found
that Ext3 with "data=journal" option was about 50% faster than the next
fastest options (XFS and ext3 with "data=writeback"). Again, this is
because synchronous meta-data, as well as normal synchronous file data,
can be written sequentially in the FS journal at peak IO speed. If I can
find the figures, I'll post them. However, I mislaid the test results and
haven't got a suitable machine to reproduce at the moment.
> --
> D. Richard Hipp
>
Christian
PS. If people are after maximum performance, I can recommend ext3 with
"data=journal" option for SQLite. The performance is stunning!
PPS. Merry Christmas to those so inclined.
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
